Building clang in buildworld as part of the bootstrap process -- is it really necessary?

[Warner Losh]

On Sep 6, 2014, at 5:28 AM, David Chisnall <theraven at FreeBSD.org> wrote:

> On 6 Sep 2014, at 06:47, Garrett Cooper <yaneurabeya at gmail.com> wrote:
> 
>> Makes sense. I'll do some poking around and see if things could potentially be optimized with the clang build. On beefy machines it's not a big deal, but as we know on machines without a ton of memory or SSDs, it can become painful, as expected.
> 
> The build system for clang-in-base has improved a bit so, as you say, it is now reasonably fast on beefy machines (release clang build with the upstream build system takes 2-3 minutes on a fast machine, about 10 on my laptop, the one in buildworld isn't quite as good at extracting parallelism).  On slow machines, it can be quite painful.

Yes. Hence the ask for a faster way to rebuild the system.

> The correct solution to this problem is likely to be to start creating bootstrap-toolchain packages.  This is also likely to be necessary for architectures like MIPS and PowerPC before 11 anyway, because the host compiler doesn't have the C++11 support required for bootstrapping a newer LLVM and clang.  We can work around that quite easily if we have package for the bootstrap toolchain (possibly cross-compiled from an x86 machine).

I’m not sure which problem this solves.

If you are cross building, then you already are likely running on amd64 which has a good compiler. If you are doing a native build, then everybody but mips and armeb already have clang support in the base. For those what you do with clang is irrelevant, so long as gcc is around.

When gcc is kicked out of the base, we’ll need to have an external toolchain story for those platforms anyway. That story might include generation of binary packages, but it will also need to include building of those packages easily. Likely without buildworld, or a modified variant that groks how to bootstrap a sysroot.

Cross building for ports is getting close, we may be able to use it to generate packages for nonx86 faster than native (recent successful full builds are taking only 5x as long).

I guess I’m saying that while packages may be necessary, they aren’t sufficient unless they are easily reproduced.

All this also needs to be well documented, or we’re going to go off the rails trying to support it.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20140906/90d39b6f/attachment.sig>