Date: Thu, 18 Dec 2014 15:44:12 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Robert Huff <roberthuff@rcn.com> Cc: FreeBSD ARM <freebsd-arm@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org>, FreeBSD ports <freebsd-ports@freebsd.org>, NGie Cooper <yaneurabeya@gmail.com> Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Message-ID: <E2670EBE-CD53-43D5-89EA-DC5460849BE5@FreeBSD.org> In-Reply-To: <21650.55288.425711.209975@jerusalem.litteratus.org> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <CAGHfRMBPkQiTgW0Eahkoe1QwArBst-BZ-Lawor_CDda1x8K9xg@mail.gmail.com> <D9C5A8D1-2158-4B37-9C9C-067A4DDE6E44@FreeBSD.org> <21650.55288.425711.209975@jerusalem.litteratus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_80B4A968-C08E-4E17-B794-34BE8ACDEBA6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 18 Dec 2014, at 14:34, Robert Huff wrote: > Dimitry Andric writes: > >>> - Could a "MK_CLANG_ALL_TARGETS" or something similar option be >>> added to src.opts.mk to fine tune this process for those of us who >>> don't want to build a cross-compile toolchain every iteration for our >>> target MACHINE/MACHINE_ARCH? >> >> I would be fine with something like this, as long as it is turned off by >> default, or if it is only used for the bootstrap stages. It is actually >> an extremely useful feature of clang that you can target multiple >> architectures with one compiler binary. > > Point of information: this seems useful for developers, and > (almost entirely) useless for everyone else. Are there other > cohorts that want this badly? > If that's correct, and there's a simple switch for > configuration ... why should this default to what's useful for the > (much?) smaller number of people? About what am I ignorant? It's not a simple switch, at least not now. If you use the upstream build system for llvm, e.g. autoconf or CMake, it has an option to select all the architectures that are supported. Several config files are then generated differently, and parts of the target support subdirectories are selectively enabled or disabled. In fact, we already build just a subset of the available architectures, since FreeBSD only supports about 5 of them. We can probably arrange for a more minimal configuration in our build system, but since the build time saved is quite small, I don't think it makes much sense in complicating our build system even further. If people are really so interested in shaving off a little, for more complication, that is fine with me. But unfortunately, I have too many tasks on my plate right now, and I cannot work on it. Besides, doing such a new feature now would interfere with the current branch work. Also, after the 3.5.0 import, there are much more interesting fish to fry, in my opinion. For example, importing newer versions of libc++ and compiler-rt, which can bring address sanitizer support, etc. -Dimitry --Apple-Mail=_80B4A968-C08E-4E17-B794-34BE8ACDEBA6 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.26 iEYEARECAAYFAlSS6EQACgkQsF6jCi4glqOINgCgtxznuS7Lp1GZzdsGdaVA5H/t 0GIAoNqaW8VrXZUqBlJqhaqvx97ggMWA =vrEg -----END PGP SIGNATURE----- --Apple-Mail=_80B4A968-C08E-4E17-B794-34BE8ACDEBA6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E2670EBE-CD53-43D5-89EA-DC5460849BE5>