Re: Initial LLVM/clang patch

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Thu, Feb 03, 2011 at 04:39:12PM +0100, Alistair Crooks wrote:
> Hi Joerg,
> 
> On Thu, Feb 03, 2011 at 02:08:30AM +0100, Joerg Sonnenberger wrote:
> > attached patch + tarball contain enough magic to get a working clang for
> > AMD64. I could like to get this into the tree to make it simpler to test
> > and integrated the changes required for doing a (almost) full world
> > build. Things like support for !x86 targets in clang etc can be provided
> > incrementally as well.
> 
> It would be great to get more support for external toolchains into the
> tree.  This will become more and more important over the next few
> years.

I am working on cleaning up the compiler part of that in src/share/mk
and make it easier to use different compilers for different parts of the
tree. The biggest issue with that right now is libgcc and libstdc++ --
I'm not sure of the legal implications of building either with !GCC...

> > At the moment, I do not plan to import the upstream LLVM or clang
> > sources. src/external/llvm/Makefile has a checkout target using svn to
> > get the "proven" revision as specified in Makefile.inc. This avoids
> > having to deal with regular imports and repo churn associated.
> 
> That's a neat trick, but I feel it's not the right way to attack the
> issues:
> 
> 1.  checking existing version informatino, and optionally downloading,
> verifying integrity, making sure pre-reqs are in place, configuring
> for the host, building and packaging up the result are best done in
> pkgsrc - that's what it's designed for.  Re-inventing a subset of this
> in src strikes of point solutions and re-inventing wheels.

I'll use the same argument for why xsrc was survived -- it is easier to
test integration and use the cross-compiling toolchain this way. The
only part where reusing pkgsrc infrastructure would be in any way
helpful is "downloading" and "verifying integrity". I am willing to put
a certain degree of trust into the integrity of the upstream repository
to not care about that part for now. The "downloading" part would be as
hackish in pkgsrc as this is intentionally using trunk of both llvm and
clang.

I do not want to keep this an external toolchain, but I would prefer to
deal directly with the upstream source until at least the x86 builds can
finish.

> 2. Doing this in src means that no binary packages for the toolchain.
> For me, that's a necessity for an external toolchain.

There is a separate clang package in pkgsrc already. I think that one is
using the last release, so missing certain important parts. It also
can't provide installation as part of base etc. They are different
beasts and should IMO be handled as such.

> 3. serious build farms are in walled off areas, accessible only through
> draconian security measures. All output is signed, and snapshots are
> taken and preserved of the results. That might prove problematic for
> this implementation.

At this point the feature is completely optional and the checkout target
is just a helper target to make it easier to access. You can just as
well extract a golden tarball. Again, I don't consider this as long term
solution, but to ease the development for now.

> 4. A subversion client is needed to do this, so we need some form of
> pkgsrc installed. We've always taken the view that the tools needed to
> download and build src are in src - hence cvs's presence, etc. To me,
> this is asking a bit too much.

See above.

Joerg