Re: Installation proposal

[Stan Shebs <shebs at apple dot com>]

Mark Mitchell wrote:
> 
> Read this unless you are willing to let me change the build process around
> somewhat dramatically without knowing what I'm going to do.
> 
> I got to thinking about the idea that I brought up yesterday regarding
> installation.
> 
> In particular, here's what I had in mind:
> 
> 1. Create a subdirectory of the objdir called "install".
> 
> 2. Treat install as if it were the final prefix during building --
>    put everything in there.  That means that there will be directories
>    like "install/bin", "install/lib", and so forth.  So, "make" would
>    just drop everything in these directories.
> 
> 3. At install time, run a single script which copies everything in
>    install into prefix.

This is actually very similar to what Apple does for Mac OS X.
The final install place is called the "dstroot", and is an image
of what will be installed.  This works well across a wide range
of projects, because then you can have a single set of tools and
scripts that scan dstroots for permissions, setuid programs, and
other potential security holes.

It's also useful for building a complete system incrementally,
by merging in dstroots, then doing a chroot to try it out.

Stan

> What's good about this?
> 
> 1. The testing we do is much more like the testing the user will do.
> 
>    In particular, to test, say, g++, we would just run
>    "install/bin/g++", not "g++ -B... -nostdinc++ -I..."
> 
> 2. The testsuites could forget about multilibs.  They will now just
>    work the way they do when users actually use the compiler.  (Right
>    now, the testsuites have to futz around with the -I paths and -L
>    paths to find everything correctly.  Thus this logic is duplicated
>    between the compiler and the testsuite.)
> 
> 3. We would test that our installations are really location-independent,
>    which they supposedly are.  (They certainly should be; other vendors
>    have done this with their compilers for a decade, and its very
>    handy.)
> 
> 4. It's much easier to ensure consistent permissions and such in the
>    final installation if there's only one place where installations
>    are happening.  You can make sure that everything has the same
>    ownership, same modes, etc.  It's also easy to use something
>    faster than install-sh when you have it because there's only one
>    place you need to do it.
> 
> Now, I thought that this would be a horrific pain because I'd have to
> change all the make rules everywhere to drop their outputs in the
> "install" directory.
> 
> But, I realized that we can put that off, even though it would be good
> to do at some point.
> 
> We can just have the top-level configure set the prefix for all of the
> child configures to "install".  Then, have the top-level "make" and
> "make bootstrap" do what they do now, plus "make install" in all of
> the children.  Then, have the top-level "make install" do the copying
> step.  Sounds like one day's work to get it working, and another one
> to debug the fallout.
> 
> I would like to implement this and check it in for GCC 3.2.
> 
> I can't believe there won't be debate.  Still, if nobody objects in a
> few days, this is what I'll do.
> 
> --
> Mark Mitchell                mark@codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com