From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 6 14:46:18 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 0B74570E for ; Sat, 6 Sep 2014 14:46:18 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0FD01E7B for ; Sat, 6 Sep 2014 14:46:17 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id hn18so764567igb.13 for ; Sat, 06 Sep 2014 07:46:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=92BszKoF8uipq1K/ZJmK0RjW4hTFrO9VdJz1NqQExo8=; b=T5H2VtWMjkkQEHJ+Q9GJP3Z8MVUIb2Z4X0jGbwEiqXXy6ohlc1liWems96qnuJesLH l8cWSwqg/yuw3ayK1w/tB0AJgqUl7lRt/qB+UMHJavrKOJvhqipPE9/+1gTYPyxnZi33 Jim+XOwMk1O7BsMJrYxDaWvA5y74vKhHmdj+0YxLsinir/m/MPWYtPFqHzu2I2/YMMep qOYKsxVZSOdR1I0BZDKZRORLq65UQH3Qg+xarOSf1rxXpwQ/U7ue3tn2LLQByN03dOuJ Dr09ctjpAI6M7hi3b8Y1vZgcMbKk9c5tna+No9qMd+4QSkrX3Pt+ei4Hjz0KwU5+1nbv NmfQ== X-Gm-Message-State: ALoCoQndsUq5Lu+vSSuNG0BNCNlrbIeZDssoaSl+ud+NVxqOgbO+Kdndjv21+IXuxMkh46ii8pyk X-Received: by 10.51.17.66 with SMTP id gc2mr12507484igd.40.1410014771426; Sat, 06 Sep 2014 07:46:11 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id m4sm6234997igr.20.2014.09.06.07.46.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Sep 2014 07:46:10 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_9BE5E8FF-B8DF-4BEE-972E-F6A58703A481"; protocol="application/pgp-signature"; micalg=pgp-sha512 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: Warner Losh In-Reply-To: <333A99CA-014B-47F8-A146-A439611A8A80@FreeBSD.org> Date: Sat, 6 Sep 2014 08:46:07 -0600 Message-Id: <91F5D06E-CF51-4659-A52F-4512061BF6F0@bsdimp.com> References: <01C283B7-C9AF-4AE8-A192-FBC7C04D207E@bsdimp.com> <333A99CA-014B-47F8-A146-A439611A8A80@FreeBSD.org> To: Dimitry Andric 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 14:46:18 -0000 --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 wrote: > 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. >=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--