Date: Sat, 6 Sep 2014 08:46:07 -0600 From: Warner Losh <imp@bsdimp.com> To: Dimitry Andric <dim@FreeBSD.org> 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: <91F5D06E-CF51-4659-A52F-4512061BF6F0@bsdimp.com> In-Reply-To: <333A99CA-014B-47F8-A146-A439611A8A80@FreeBSD.org> References: <CAGHfRMD0Tm14p%2Bv=%2B6mp89eb4TSNenPSPn92XKC2XbM8m6Ut=g@mail.gmail.com> <01C283B7-C9AF-4AE8-A192-FBC7C04D207E@bsdimp.com> <333A99CA-014B-47F8-A146-A439611A8A80@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_9BE5E8FF-B8DF-4BEE-972E-F6A58703A481 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 6, 2014, at 5:32 AM, Dimitry Andric <dim@FreeBSD.org> wrote: > 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. >=20 > 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. >=20 > 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. Yes. Some use cases work, others don=92t. >=20 >>> 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. >=20 > 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. We=92ve avoided playing the =93optimize the build=94 game for = buildworld. while we do make some exceptions for minor, ancillary tools, = we always assume a full build will always work, and that=92s the only = way the project supports people. >> It is also installed as cc. >=20 > That's actually another copy, the one built during the later stages. = It > might not even run on the host system. :) True. My point in mentioning this is that you don=92t get cc unless you = build clang or gcc in base. >=20 >> 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. >=20 > 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. buildwolrd -DNO_CLEAN already does that... > 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. >=20 > I would really like for incremental buildworld to become more robust. = :) I would too. However, every time clang gets upgraded, it clang seems to = break the no_clean case :( There are also other offenders, but we=92ve = not had smooth sailing in the upgrade with NO_CLEAN stuff for a long = time, hence my caution. jbuild shoed a lot of promise. We need to get that done if we want to = get away from all this crazy. Warner --Apple-Mail=_9BE5E8FF-B8DF-4BEE-972E-F6A58703A481 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUCx4vAAoJEGwc0Sh9sBEAoYYQAIDRbxO4MnU/nYsXA9IOTs8K 3LJUfOlOJjId9kw/Py+IHYhOac7WyXbzGlVG4TqFoWWwZJBY8c9YfZbO32+S0pTZ /12Fi4xduYFxsDMzbO70RVdmePZY2GJS8DC9rQm2018a4oUHkY8H4gyD5VuqOuV5 soAJqRv0D5k14nnjo2Ff/NuxiIvwQVKGJV8gSBbAKK9rLSBkFB6BAU9CNQ9c1Z86 2rG0gz4irBJyiFDHGvdY8zoMXGP5OUMN1RRMYT2Q6HmU4QRQhu2wwGG14zrbWxBr gNK4BVaPuuYTzrlqSPHW8BD6CZpOCLNHY39A+cz5DaxB2c+iTkdcrPBtaQz6qxQo zqWxwLnXlad3CZn99gjlakWB7hPfM5w5ZDyQjieD8K1NAhYVvXBkuqR9hx1285C5 YzJgtMiboUkxwUbDzgcDs9RJyLfze8H7es0uBAgh58Zm/R+ple3tKIUDEH3vN56Q w0X/bC73MLpW7Xss0a87YnKJhCH2OK8SSrPtsekDY9Qfigk37/dRuWiMGh2YJcRW z7x5w5JjQM5raxyadtEcvPEw4JazQjVjvfhniGLK3MzsKl2cn2chtdu2GC4fJdps nCmIcGMtRpgpMfjByinmpxjgeTHeZ6LJth9DorWZAq5W9XrOn//1/AZ19nP20NJj LE0nbsbmd7+NQBcyHTEw =D9eb -----END PGP SIGNATURE----- --Apple-Mail=_9BE5E8FF-B8DF-4BEE-972E-F6A58703A481--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91F5D06E-CF51-4659-A52F-4512061BF6F0>