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

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

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