Re: Shell wrappers and GCC - FYA

["Zack Weinberg" <zackw at Stanford dot EDU>]

On Fri, Jun 29, 2001 at 07:03:31AM +0100, Neil Booth wrote:
> Zack Weinberg wrote:-
> 
> > One of my deep-future projects is to get Make to run cc1 directly,
> > cutting out all the overhead associated with the driver.  There'd
> > still be a chunk of code executing in Make's process that did the
> > argument munging, of course.
> 
> I don't quite see what you have in mind here.  Would this "make" be
> called gccMake or something, be derived from GNU make, and only be
> distributed with gcc?  For people who only have normal makes I assume
> we still have a driver?

Cleverer than that.

Suppose that

$ gcc -print-dynamic-driver

spits out something like

/usr/lib/gcc-lib/TARGET/3.2/libdriver.so

Make dlopens that path.  It provides a single documented entry point,
which make can call with an argument vector.  This has the same effect
as spawning a child process to execute gcc with that argument vector.
The changes to make are minimal.  Naturally, /usr/bin/gcc continues to
work normally (it may do the same dlopen+call sequence under the hood).

There are thre problems I see.  One is, it's not clear how to handle
language-specific drivers, unless you want to have libgccdriver.so,
libg++driver.so, etc. etc.  which strikes me as horrid.  Another is
making the library play nice with make when both of them want to be in
charge of calling wait(2).  And the final problem is how does make
tell when it's supposed to try the magic -print-dynamic-driver switch?
(Obviously it does that only once per make invocation, or what's the
point?)

-- 
zw  But then one day I came up with a radical new paradigm for my business...
    I decided that from now on I would only sell boring stuff that people
    actually need.
    	-- Garry Trudeau, _Doonesbury_