Re: Initial LLVM/clang patch

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Thu, Feb 03, 2011 at 06:04:28PM +0200, Antti Kantee wrote:
> On Thu Feb 03 2011 at 16:39:12 +0100, Alistair Crooks wrote:
> > > 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:
> 
> To me it sounds like a great idea to make development smoother, at least
> while llvm is experimental.
> 
> We discussed a similar approach even for non-experimental toolchains in
> the 20101101 core meeting, but there was no clear consensus on that.
> This experiment will allow us to better see the pros and cons of such
> an approach.
>
> > 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.
> 
> Seems like the only required action is "make checkout" which runs two
> svn commands.

If you start going down this route, then version information needs to be
retained somewhere for the external toolchain. Some minimum versino to build
the source tree needs to be placed in the source tree.

Logic for comparing these two is required.

A subversion client is required.

> > 2. Doing this in src means that no binary packages for the toolchain.
> 
> why?

pkgsrc makes one for you by doing "make package". I can take the result,
optionally sign it, and move it to any machine I want and use it there.

Now I'm sure it's possible to just tar up the external toolchain you've
built, and carry it around with you, but the basic mode of behaviour is
the same - everything you are doing is reproducing, in a different way,
with less testing, and with less features, what pkgsrc gives you for free.
On a number of platforms.

I'm not into luddite or amish games - neither am i advocating nih and a
"damn external toolchains" attitude. What I am saying is that a "hey,
let's do this for now, it's much easier, it's easy, it's simple" approach
has some drawbacks.
 
> > For me, that's a necessity for an external toolchain.
> 
> > 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.
> > 
> > 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.
> 
> While these are good points for an officially supported toolchain,
> I don't think they matter, quoting Joerg, "at the moment".

I don't want to start thinking about the number of demos, prototypes and
research items I have had to support in production - and not just the ones
I wrote either.

You haven't addressed my point, though - why are you trying to
re-invent pkgsrc?

Regards,
Alistair