Re: Installation proposal

[Joel Sherrill <joel dot sherrill at OARcorp 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.
> 
> What's good about this?

This is generally what RTEMS does and it does make things more
consistent between build and install images.  I am sure there
are warts to work out but it will certainly cut down on keeping
track of include paths in multiple places.  One thought is that
other packages that are usually part of the "one tree" build
might have to go this way as well.  newlib comes to mind as
one such package, I am sure there will be others.

> 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..."

This seems like a good thing if the details are worked out.
 
> 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.)

This would be a great thing from a maintenance and consistency 
standpoint.

I also suspect it would fix the core dump I see when trying to
test *-rtems targets since we use a -B... -specs BOARD_specs to 
augment gcc's notion of linking.
 
> 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.)

This is certainly a weakness in gcc right now.  It is hard to explain
to someone using prebuilt binaries why they shouldn't be relocated.  I
see people setting GCC_EXEC_PREFIX for their native or cross GCC and 
breaking the other.  

> 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.

RTEMS installs with a tar piped into a cd/tar combination so I can
see this.

> 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.

There are a lot of details to work out and there will be some
consistency
issues with other packages but it should be a great simplification.

> 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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985