Prev: commit PR ports/146582: [PATCH]textproc/libxml2
Next: nvidia-driver 256.35 released
From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= on 22 Jun 2010 11:23
Hi list,

One of the things I've been working on for the past few weeks is
creating an easy way to change ports compiler without breaking things
that shouldn't break "just" because compiler changed. Some of the
current problems are mentioned on the wiki page[1]. Something not
mentioned there is that it is difficult to set compiler only for ports
and not for base system/everything else.

I've implemented PORTS_CC, which, at the moment, properly handles all
versions of GCC in ports and clang. Another new thing is USE_CC, which
does very similar job to USE_GCC, but also works for clang.

Valid values for PORTS_CC are gcc, gccXY and clang. Everything else is
mostly unhandled and just does CC=${PORTS_CC} CXX=${PORTS_CXX}. If
PORTS_CC is set to some version of gcc or clang, PORTS_CXX isn't used
and CXX is set automatically.

What is USE_CC:
USE_CC=gcc4.2+ does exactly the same thing as USE_GCC=4.2+, not really
interesting. USE_CC=clang forces the port to use clang. More interesting
is USE_CC="gcc4.4 clang" - if PORTS_CC is set to some version of gcc,
use gcc44, if PORTS_CC is set to clang, use clang. Another thing to note
is that USE_{CC,GCC} don't unconditionally override the compiler, for
example if PORTS_CC=gcc45 and USE_GCC=4.4+, gcc45 will be used, because
USE_GCC allows higher versions. USE_CC=gcc is a bit special, if gcc
version is not specified, port will use gcc from base system.

Since I'm testing ports with clang, I don't always want ports to respect
USE_GCC, that's why I've added NO_USE_CC. When defined, it forces
USE_GCC and USE_CC to be ignored.

One of the problems that I haven't solved yet is that ports never had to
care about the compiler, it was just there. That's why now there's no "I
want to use gcc45 as my ports compiler, so install it" switch. Adding
build depend is tricky because of recursive dependencies. I do have some
ideas how to fix it, but I haven't tested them yet.

If you want to try this, download bsd.*.mk files[2] (diffs are here[3]),
put them in /usr/ports/Mk/, put PORTS_CC=gcc44 (or whatever you want) in
make.conf, pray a little and try to build some ports. If you don't put
anything in make.conf, gcc from base will be used. PORTS_CC will ignore
any CC/CXX magic you have in make.conf.

If you're feeling adventurous, you can try building ports with clang:
Put PORTS_CC=clang to make.conf, apply all the patches[4] for ports,
rebuild devel/libtool22, pray even more than before, and try to build
stuff. Just remember that THINGS WILL BREAK, many ports don't compile
with clang yet. As a workaround, you can put USE_CC=gcc in port's
makefile to build it with gcc instead of clang. Don't report broken
ports unless clang miscompiles something. If something goes wrong you
can always do "portsnap extract" to clean the ports tree.


If you have suggestions how to improve something, questions or some
other feedback, I'm listening.

[1] http://wiki.freebsd.org/SOC2010AndriusMorkunas
[2] http://rainbow-runner.nl/~andrius/soc/ports/Mk/
[3] http://rainbow-runner.nl/~andrius/soc/patches/
[4] http://rainbow-runner.nl/clang/patches/

--
Andrius
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

 | 
Pages: 1
Prev: commit PR ports/146582: [PATCH]textproc/libxml2
Next: nvidia-driver 256.35 released