Re: Shell wrappers and GCC - FYAu

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <20010629225211.B8940@hg.cs.mu.oz.au> you write:
>On 29-Jun-2001, Joern Rennecke <amylaar@redhat.com> wrote:
>> > 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?)
>> 
>> Maybe you should set an environmnment variable to the output of
>> gcc -print-dynamic-driver to enable this scheme.

>Basically what you want is a generic way for `make' to invoke a shared
>library entry point rather than spawning a new process.

However, this does assume the corresponding shared library has a quick way
to clean up its slate for a new compile.

I'm not at all sure there's any benefit to be had on a modern operating 
system. Specifically, the program is more or less already loaded, and what
exec actually does is just re-read the data section(s) from disk---which is
equivalent to resetting that slate.

The performance hit in make does not come from forking gcc, but from forking
an extra shell... If you can manage to get the compiler lines simple enough,
and let make detect that, and avoid the extra shell, you WILL win, and it's
much simpler than redesigning gcc...

As far as performance hits go, recursive makes are probably a larger evil,
as we know. But designing a make that would alleviate that issue would 
probably break every standard in existence (how to write a make with local
namespaces...)