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]

Re: Installation proposal

Jim Wilson wrote:

> If the install is overwriting /usr/bin/gcc, then it is a really good idea
> to test it before installing it.  I don't recommend doing builds that way,
> but some people do.

People installing a system compiler have probably their own
install and test system (like recompiling the kernel, then checking the
build of a few gigabytes of free software). We probably
look like testing amateurs to them :).

Who is seriously using configure with prefix /usr on a regular basis?

> If you are building something to install in a location that you don't have
> write access to, then you can still test it.  Otherwise, you need to su root
> first before you can test it.

If our accepted target is location independance, then this argument is void.

My own user policy is all root stuff is installed through binary
packaging systems, everything else is installed with user
permission (other solution I used where far worse :).

The ACT GNAT install process is location independant
and it does so by having a 10 line wrapper script that sets the needed 
env var and
then call the real bin for all of its tools (using $0).

> It makes the code-test-debug cycle faster, if you don't have to do an install
> after writing code and before testing it.  

Full C+Ada install is 65s on my machine (boot is 47 minutes, check is 28 
ACATS is 32 minutes). Doesn't look like a real argument. Plus as far as 
I can
judge people code-test-debug on one test file (the bug) by using
gdb on xx1, they don't run the full test suite after each one line change,
they run it once it works reasonably on their test case, then bootstrap
+ check is going to take a while but install time is irrelevant then.

 > It also saves on disk space during the development cycle.

With C+Ada install takes less space than a stage, and about 25%
of a full make boostrap. If you are this short on space, then
I don't even see how you can do any development work.

> But yes, when you get to the point where you are making a release, it is
> mandatory to test the installed compiler.  

And release are where we should be good on testing (easy to automate,
testing what user will see). Why not use the same thing while developing?
If we don't then all the trouble is for our loved release manager at
release time :).

> The current testsuites can be used
> to test an installed compiler if there is no compiler in the build tree.

Is this documented? (I remember only seeing "make -k check").
I would be *really* interested.

Laurent Guerby <>

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