Re: egcs testsuite & dejagnu : A special case?

[Craig Burley <burley@gnu.org>]

>Would you mind giving an exact description of the gcc invokation
>etc that you have in mind, and what it will exactly accomplish?
>I am not worried about the patch itself; however it is still unclear
>what the `user interface' will become.  I am thinking about a short
>alinea that describes the syntax and a few example locations of the
>involved files.

Essentially, the idea I have is that, after `make' or `make bootstrap'
in gcc (or above in egcs, of course), and given that /home/me/egcs/gcc
is the name of the gcc build directory, the command (shell script)

  /home/me/egcs/gcc/etc/gcc ...

has "exactly" the same behavior as would, the sequence

  make install
  /usr/bin/gcc ...

(assuming --prefix=/usr during configuration).

And, "exactly" is quoted because it's probably not possible to make
it exact, but at least to get the equivalent of using the proper
-B and -L options, plus whatever other options are appropriate.

And, to clarify, /home/me/egcs/gcc/etc/gcc would be copyable to and
runnable from anywhere, but still work the same way.  So it'd contain
absolute pathnames.

For example, the contents of /home/me/egcs/gcc might be (AFAIK):

  #!/bin/sh
  /home/me/egcs/gcc/xgcc -B/home/me/egcs/gcc/ -L/home/me/egcs/gcc $*

It seems pretty straightforward to implement.  The tricks are getting
the options right (which might be, in the strictest sense, impossible,
but if it covers most of "exactly", it's worth doing and worrying
about the rest later) and modifying the build procedures so anything
important vis-a-vis such a command currently done during `make install'
is done during `make [bootstrap]' instead.  (I don't think building
the Info docs is an example of that.  There might be nothing like
this that needs to be done, but it's worth taking a look as part of
this project.)

Repeat the above for any other command/script installed by `make
install' that depends on built-in knowledge of the *installation*
location, and thus needs to be explicitly told to look in the build
directory instead.

So, include g++, g77, and other languages' drivers in that -- there
would therefore be .../etc/g++, ../etc/g77, and perhaps others as
well.  (I'm guessing protoize and unprotoize don't *need* to be
encapsulated this way, but perhaps they should be, or links made using
absolute symbolic, or hard, links, for completeness.  That'd be
kinda nice -- "ls etc" in a gcc build directory would be a quick
way to list all the "exported" commands that are normally installed,
which sysadmins and hackers of all sorts might appreciate.)

The impact of doing this should be that running an arbitrary
test suite, or building anything else that takes an arbitrary
`CC=whatever' definition, can simply be pointed to the .../etc/
pathname that is appropriate (heck, .../etc/gcc could even be
installed as /usr/bin/cc if someone was brave enough) without
having to worry about -B and -L options, or whatever else
a given version of gcc might need to run properly out of the
build directory.

(Of course, once the build directory is blown away, the script
stops working.  The behavior in such a case should be appropriate,
i.e. a not-found message and error status code returned by the
script.)

        tq vm, (burley)