This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Installation proposal
- From: Mark Mitchell <mark at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 27 Feb 2002 09:56:28 -0800
- Subject: 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
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?
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