Installation proposal

[Laurent Guerby]

Mark Mitchell wrote:

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

Testing anything but the installed compiler is a mistake, the testsuite
should be completely separated from the build process, and running
the test suite should take place after the install step IMHO.

I never understood what are the advantage (if any) of tying the
testsuite run to the build process, any info? I can list
only disadvantages...


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

One point that would be nice for test suite technology would
be a gcc flag or tool generating normalized output giving information
about what is available to test (targets, languages, etc...).

I assume most of the information is already available by
combining existing flags, but then even we don't modify the driver
a documented and maintained (accross driver changes)
script using the driver producing such information would be great.

-- 
Laurent Guerby <guerby@acm.org>