This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Installation proposal

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

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?

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

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      
CodeSourcery, LLC  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]