From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 6 11:32:54 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECE7725F for ; Sat, 6 Sep 2014 11:32:54 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 73A861AF2 for ; Sat, 6 Sep 2014 11:32:54 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::410d:d7df:2b8e:d4bf] (unknown [IPv6:2001:7b8:3a7:0:410d:d7df:2b8e:d4bf]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EB252B803; Sat, 6 Sep 2014 13:32:44 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_407B3BD6-F01E-46F4-B9CB-F020C3C5D3E0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Building clang in buildworld as part of the bootstrap process -- is it really necessary? From: Dimitry Andric In-Reply-To: <01C283B7-C9AF-4AE8-A192-FBC7C04D207E@bsdimp.com> Date: Sat, 6 Sep 2014 13:32:31 +0200 Message-Id: <333A99CA-014B-47F8-A146-A439611A8A80@FreeBSD.org> References: <01C283B7-C9AF-4AE8-A192-FBC7C04D207E@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-toolchain@freebsd.org, conrad.meyer@emc.com, Garrett Cooper X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 11:32:55 -0000 --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 wrote: >=20 > On Sep 5, 2014, at 8:21 PM, Garrett Cooper = 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--