From mboxrd@z Thu Jan 1 00:00:00 1970 From: Craig Burley To: carlo@runaway.xs4all.nl Cc: egcs@cygnus.com Subject: Re: egcs testsuite & dejagnu : A special case? Date: Fri, 03 Jul 1998 00:12:00 -0000 Message-id: <199807021947.PAA28861@melange.gnu.org> References: <199807021422.QAA19572@jolan.ppro> X-SW-Source: 1998-07/msg00116.html >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)