On 06 Sep 2014, at 05:16, Warner Losh <[email protected]> wrote: > > On Sep 5, 2014, at 8:21 PM, Garrett Cooper <[email protected]> wrote: >> >> One of the questions that came up from a co-worker is "why do I >> need to build clang in buildworld if I already installed it from >> ports"? I could see some valid reasons for doing this (one needs a >> cross-compiler, one might need specific options that might not be set >> in the ports version), but for native builds I would tend to agree >> with this logic.
For one, the base version of clang has a number of patches which haven't yet been sent upstream (and might never be). I see the port already has a few of them, but certainly not all. That said, the ultimate goal is obviously to be able to build world with a stock version of an external compiler, be it clang or gcc. There is still quite a lot to be done to make that possible. >> With gcc it was wasteful building the compiler each >> buildworld, but with clang it seems annoying continuing on this path >> because the compile takes a long time to complete. > > The clang built during buildworld is used to bootstrap. So it is required > sometimes. Usually when there’s a binary compatibility issue, which is rare > but does happen. We already do something similar with BOOTSTRAPPING, where we attempt to detect which build tools on the host system are too old, and build them accordingly. I think something like this might also be possible for the toolchain components, for example by using the __FreeBSD_cc_version built-in define (which is also in our gcc, but it doesn't seem to be used very often). Or some other system entirely. > It is also installed as cc. That's actually another copy, the one built during the later stages. It might not even run on the host system. :) > The ports clang may or may not build the world. However, if you want to say > “I know what I’m doing” you can set WITHOUT_CLANG_BOOTSTRAP and > WITHOUT_GCC_BOOTSTRAP to tell the build to do no building of bootstrap tools > and to use the host’s instead. This usually works, but may fail from time to > time with port-built compilers. > > If you don’t want buildworld to build any compiler, you can add > WITHOUT_CLANG=t and WITHOUT_GCC=t. This will create the system without any > compilers. You’ll need to set CC to /usr/local/bin/clang35 or whatever as > well. There may be other settings you need as well. > >> Alternatively, would anyone be opposed to adding some logic to >> automatically bypass the bootstrap compiler, i.e. add some logic to >> Makefile.inc1 that would skip compiling clang/gcc if and only if the >> target triplet and version met some required values? > > There’s enough violent opposition to this that it will never happen. > buildworld is supposed to always be safe. Don’t mess with that. It isn’t > designed to be fast. Yup, though in most cases, it should be sufficient to do an incremental buildworld instead of a "full" one. This would also prevent rebuilding any part of llvm and/or clang, as long as no changes occur in them. For example, the only recent change to clang was in one of the ARM target's .td files (to fix a problem with movw being sometimes emitted on ARMv6). In this case, only a bunch of .inc files will be regenerated and some of the files under lib/clang/libllvmarm* will be rebuilt, but certainly not the entire llvm and clang codebase. I would really like for incremental buildworld to become more robust. :) -Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
