Re: How to disable CLANG & co build in buildworld?

In message: <4C13F53F.3050106_at_FreeBSD.org>
            Doug Barton <dougb_at_FreeBSD.org> writes:
: On 06/12/10 08:10, M. Warner Losh wrote:
: > In message:<4C1315F9.6000300_at_FreeBSD.org>
: >              Doug Barton<dougb_at_freebsd.org>  writes:
: > : On 06/11/10 14:18, M. Warner Losh wrote:
: > :> "This" is building the proper set of tools for the target.  It is
: > easy
: > :>  to do, and only a couple lines of Makefile foo in Makefile.inc1
: > :> instead of in bsd.own.mk.  It is a fairly natural consequence of
: > the
: > :>  tbemd stuff I have been working on and have started merging.
: > :>
: > :> The consequences today are that you build some extra tools that are
: > :> only needed to build clang when in fact you aren't really going to
: > be
: > :> building clang.  The "cost" is however long it takes to do this on
: > the
: > :> platform you are building on.  This can range from a minute or two
: > to
: > :>  tens of minutes depending on the power of your build system.
: > :
: > : Ok, obviously I'm dense because I didn't understand an answer to my
: > : question anywhere in there. :) So let me try again. Why are we not
: > : optimizing for the common case, where the world is built on the
: > system
: > : it's going to run on, which means that WITHOUT_CLANG can easily mean
: > : exactly that?
: >
: > Because if we optimize for that case, we break the other cases.
: > Broken trumps fast, so we always build the clang tools.
: >
: > The reason it is broke is that the default for clang varies between
: > architectures, which makes the usual tests for MK_CLANG not work for
: > the bootstrap tools phase.
: 
: Sorry, still dense here. 

I explained it already, but I'll show the exact code...

: Can you point to code where simply testing
: for MK_CLANG won't work?

from Makefile.inc1
# XXX: There is no way to specify bootstrap tools depending on MK-flags
# with different per-architecture default values. Always build tblgen.
_clang_tblgen= \
	lib/clang/libllvmsupport \
	lib/clang/libllvmsystem \
	usr.bin/clang/tblgen

coupled with:

from bsd.own.mk:
#
# Default behaviour of MK_CLANG depends on the architecture.
#
.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386" || \
    ${MACHINE_ARCH} == "powerpc"
_clang_yes=CLANG
_clang_no=
.else
_clang_yes=
_clang_no=CLANG
.endif

so, if you add the test of MK_CLANG above for setting _clang_tblgen,
you break the following case:

neither WITH_CLANG or WITHOUT_CLANG, we go with the default:
running on sparc64 (so MACHINE_ARCH=sparc64)
building for i386 (so TARGET_ARCH=i386)

o MK_CLANG will be 'no'
o so clang's tblgen won't be built (if we added the test above you suggest)
o during the build phase MACHINE_ARCH is set to i386, so clang fails
  later because MK_CLANG will be 'yes'. 

We would do extra work for the converse (building sparc64 on a i386
host), since MK_CLANG is "yes" so we build tblgen, but never use it.
Since we always build tblgen, we fix this by degrading to this case.
This also has no change from the typical case (amd64 or i386 built on
amd64 or i386).

I plan on fixing this problem, since it also applies to WITH_FDT.  The
root cause is that WITH_foo/WITHOUT_foo works great for optional
components of the system that are basically the same everywhere
(sendmail, lpr, old toolchain), but it is horrible for communicating
intrinsic properties of the architecture (which is what is being done
here) since there's two sets of contexts where you have to ask the
question.  One where TARGET_ARCH matters, and one where MACHINE_ARCH
matters.  While the specific examples in this case might not be too
interesting, the problem it exposes is interesting to solve...

Warner