Date: Sat, 6 Sep 2014 13:32:31 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-toolchain@freebsd.org, conrad.meyer@emc.com, Garrett Cooper <yaneurabeya@gmail.com> Subject: Re: Building clang in buildworld as part of the bootstrap process -- is it really necessary? Message-ID: <333A99CA-014B-47F8-A146-A439611A8A80@FreeBSD.org> In-Reply-To: <01C283B7-C9AF-4AE8-A192-FBC7C04D207E@bsdimp.com> References: <CAGHfRMD0Tm14p%2Bv=%2B6mp89eb4TSNenPSPn92XKC2XbM8m6Ut=g@mail.gmail.com> <01C283B7-C9AF-4AE8-A192-FBC7C04D207E@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_407B3BD6-F01E-46F4-B9CB-F020C3C5D3E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 06 Sep 2014, at 05:16, Warner Losh <imp@bsdimp.com> wrote: >=20 > On Sep 5, 2014, at 8:21 PM, Garrett Cooper <yaneurabeya@gmail.com> = wrote: >>=20 >> 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. >=20 > The clang built during buildworld is used to bootstrap. So it is = required sometimes. Usually when there=92s 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 =93I know what I=92m doing=94 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=92s instead. This usually works, but = may fail from time to time with port-built compilers. >=20 > If you don=92t want buildworld to build any compiler, you can add = WITHOUT_CLANG=3Dt and WITHOUT_GCC=3Dt. This will create the system = without any compilers. You=92ll need to set CC to /usr/local/bin/clang35 = or whatever as well. There may be other settings you need as well. >=20 >> 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? >=20 > There=92s enough violent opposition to this that it will never happen. = buildworld is supposed to always be safe. Don=92t mess with that. It = isn=92t 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 --Apple-Mail=_407B3BD6-F01E-46F4-B9CB-F020C3C5D3E0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlQK8NMACgkQsF6jCi4glqP0ywCeJw9fy+0vzz8dg8CeMFQdHBln MogAn0edRn9qB0FDJdWH1pwFwEkx42/T =QSaW -----END PGP SIGNATURE----- --Apple-Mail=_407B3BD6-F01E-46F4-B9CB-F020C3C5D3E0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?333A99CA-014B-47F8-A146-A439611A8A80>