This is the mail archive of the
mailing list for the GCC project.
Re: Installation proposal
- From: Laurent Guerby <guerby at acm dot org>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 27 Feb 2002 20:03:05 +0100
- Subject: Re: Installation proposal
- References: <email@example.com>
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
> 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 <firstname.lastname@example.org>