As long as we're talking about clang, I have two questions.
    1) Is there any generic reason why a port compiled with clang
won't work on a world compiled with gcc?
    2) If not, how do I set that up?

                    Robert Huff

/etc/make.conf :

.if !empty(.CURDIR:M/usr/ports/*)
<set clang as you like>
.endif

clang for ports, YMMV as always.

http://wiki.freebsd.org/PortsAndClang

"libreoffice 3.5.x builds and run sucessfully
with clang 3.0 and (upcoming) 3.1" - @bapt

So wait for libreoffice 3.5 for clang support.

Yes but setting that does not seem to affect the ports build operation -
make.conf or -DCC etc, Seems to be poorly implemented, setting that
should set --cc in the configure, etc.

Not an option ATM.

No, none that I'm aware of.  I've occasionally seen mention of
this-or-that port causing problems if built with clang, not always
directly, but sometimes affecting other ports that depend on it.

The "standard" method is to include the following in
your /etc/make.conf (also see the comments after this):

#
# use clang unless gcc is explicitly required
#

.if !defined(USE_GCC)
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif
.endif

Over a span of several months, I've gradually amassed a list of ports
I use myself which either won't build successfully with clang, or have
some sort of runtime issues when built with clang (these have a
tendency to change over time with new releases of a given port).  For
these, I've added some "exception" lines to force them to be built
either with the base system gcc (4.2) or the lang/gcc port (4.6).

Note that these exceptions have to *precede* the previous lines in
order for them to override the above clang settings.

You can also override the clang settings at the command line by doing
"make USE_GCC=4.2 (or 4.2+)" or "make USE_GCC=4.6 (or 4.6+)", for
example.  If you do do this from the command line, just be sure to be
consistent with it, i.e., you don't want to do a "make USE_GCC=4.6
configure" followed by a plain "make" or "make install".  Pretty much
sure to lead to trouble.  :-)

Note, too, that none of these exceptions have anything to do with my
/usr/src builds.  I've been using clang for buildworld and buildkernel
for quite some time now.

###############################################################
# (need to put this up here before the following clang stuff)
#
# ports which either won't build using clang, or that have
# runtime issues when built with clang
#
##############################################################

#
# default to using clang for all port builds, with the following
# exceptions

# ports which will only build with the base system GNU compiler (4.2)
#
# the "make index" target also seems to need this, for some reason

.if target(index) | \
${.CURDIR:M*/devel/antlr*} | \
${.CURDIR:M*/devel/google-perftools* } | \
${.CURDIR:M*/graphics/ImageMagick* } | \
${.CURDIR:M*/graphics/opencv*} | \
${.CURDIR:M*/www/libxul*} | \
${.CURDIR:M*/x11/kdelibs4*} | \
${.CURDIR:M*/x11-toolkits/swt-devel*}
USE_GCC?=4.2
.endif

# ports which need *some* version of the GNU compiler (won't build with
# clang or have runtime issues if built with clang)
# use the highest version of gcc we have installed from ports (4.6)

.if ${.CURDIR:M*/accessibility/jovie*} | \
${.CURDIR:M*/accessibility/kdeaccessibility4*} | \
${.CURDIR:M*/audio/grip*} | \
${.CURDIR:M*/audio/mpg123*} | \
${.CURDIR:M*/audio/rosegarden*} | \
${.CURDIR:M*/databases/virtuoso*} | \
${.CURDIR:M*/deskutils/kdepimlibs4*} | \
${.CURDIR:M*/devel/apache-ant*} | \
${.CURDIR:M*/devel/binutils*} | \
${.CURDIR:M*/devel/icu*} | \
${.CURDIR:M*/devel/kdevelop-kde4*} | \
${.CURDIR:M*/devel/kdevplatform*} | \
${.CURDIR:M*/devel/log4j*} | \
${.CURDIR:M*/games/kdegames4*} | \
${.CURDIR:M*/graphics/tonicpoint-viewer*} | \
${.CURDIR:M*/java/* } | \
${.CURDIR:M*/lang/gcc*} | \
${.CURDIR:M*/math/fftw3*} | \
${.CURDIR:M*/multimedia/avidemux2*} | \
${.CURDIR:M*/multimedia/kdemultimedia4*} | \
${.CURDIR:M*/multimedia/vlc*} | \
${.CURDIR:M*/multimedia/xbmc*} | \
${.CURDIR:M*/net/kdenetwork4*} | \
${.CURDIR:M*/net/mpich2*} | \
${.CURDIR:M*/net/opal3*} | \
${.CURDIR:M*/net-p2p/ktorrent*} | \
${.CURDIR:M*/net-p2p/vuze*} | \
${.CURDIR:M*/sysutils/lsof*} | \
${.CURDIR:M*/textproc/docbook-xsl*} | \
${.CURDIR:M*/textproc/fop*} | \
${.CURDIR:M*/www/firefox*} | \
${.CURDIR:M*/x11/kde4-baseapps*} | \
${.CURDIR:M*/x11/kde4-workspace*} | \
${.CURDIR:M*/x11/lxpanel*} | \
${.CURDIR:M*/x11-toolkits/swt*}
USE_GCC?=4.6+
.endif

Hope this helps somewhat.  :-)

--
Conrad J. Sabatier
conrads*******

I've heard that, but I think I'll wait until it becomes the
official default.  :-)

    Very much.
    Thank you.

                    Robert Huff

I can well understand your hesitation.  I didn't jump on the clang
bandwagon for a good while myself, either.

But, from examining and comparing clang's assembly language output
against gcc's, it does seem pretty apparent that clang produces
some pretty darned efficient code, frequently using notably fewer
machine instructions than gcc, so I try to use it now as much as
possible.  I also find its error and warning messages to be much more
precise and informative than gcc's, which is a real boon if you do any
coding yourself.

There's that, plus the fact that the base system's version of gcc (4.2)
doesn't fully support my processor family type (amdfam10), whereas
clang does (although, to be fair, gcc 4.6+ does as well).

You'll come around eventually, no doubt.  :-)

--
Conrad J. Sabatier
conrads*******

Have you tried clang with ccache?  Any tricks?

No, I haven't tried that.  Actually, I don't believe I've ever even
tried using ccache at all (at least, not that I can recall).  :-)

--
Conrad J. Sabatier
conrads*******

You've piqued my curiosity here.  :-)

I'm doing a buildworld at the moment using ccache with clang.  So far,
all is well, no problems.  Didn't do anything special to get started,
just "ccache make -DNO_CLEAN -j8 buildworld" (I have all that
clang-enabling stuff already in /etc/make.conf).  I know this first run
won't really show me much, other than that it *will* compile OK.
Subsequent runs should be interesting, though.  :-)

--
Conrad J. Sabatier
conrads*******

Tell me about it. I just found the real reason why libreoffice is
failing when it gets to tests... :)

A few tests earlier today showed that with everything in cache, it took
about 1.5 to 2 times as long to build with clang versus gcc 4.2.1.  It
was faster with a full cache than without, of course: clang took 38
minutes with nothing in cache, about 12 minutes with everything cached,
and gcc buildworlds have been as fast as six minutes.  A gcc all-cached
test I just tried was 7:47.

For some reason, buildworlds on this Core I5 are much faster when
running powerd -a hadp than without.  And somewhat variable.

Well, unfortunately, I'm unable to do a successful buildworld at the
moment, with or without ccache, so the results are still up in the air
on that.  :-)

Will keep trying, though.  I *hate* when this happens!  :-)

--
Conrad J. Sabatier
conrads*******