Re: Shell wrappers and GCC - FYAu

[Fergus Henderson]

On 29-Jun-2001, Paul D. Smith <address@hidden> wrote:
> 
> I'm totally lost on the context here (what exactly are you trying to
> accomplish?) since I wasn't privy to the origins of the thread.

Sorry, I added the help-make list to the 'CC' line.
This started on the gcc mailing list.
See <http://gcc.gnu.org/ml/gcc/2001-06/msg01884.html>
for the start of this sub-thread.

> I have no real idea what
> this is supposed to do.  Is the idea that the compiler is a
> dynamically-loaded module and make would invoke the compiler as a shared
> library, instead of fork/exec?

Yes.

It could also be generalized to work with any tool that gets invoked
from make, not just compilers.

> However, I don't like adding a new magic symbol, either, if possible.  I
> would prefer something like:
> 
>   CC := $(dynload $(shell gcc -print-dynamic-driver))
> 
> or whatever.

Hmm... using a shell function `$(dynload ...)' doesn't seem quite right,
because as I envisaged it, this syntax would only make sense in command
lines, and in particular only at the start of a command line.
If there is special syntax, I think it should be a prefix on rule
command lines.

However, I agree that another cryptic symbol is not a good idea.
Perhaps just using something a bit less cryptic, e.g.
`:dynamic-load:', rather than `&', might help.

Another, possibly superior, alternative would be for make to just examine
the name of the command being invoked.  If the name is of the form "*.so"
(or "*.dll", case-insensitive), then it would first try treating it as
a shared library.

Doing different things based on the command name is a bit hacky, IMHO,
but it does avoid the need for special syntax.

For compatibility with (obfuscated) Makefiles that name executables or
shell scripts *.so or *.dll, Make should probably fall back to trying
fork/exec or forking a shell if the dlopen() or dlsym() fails.

P.S.

I suppose that you could define a shell command `$(dynload ...)'
that was analagous to `$(shell ...)' except that it worked by
dynamic loading rather than by forking a shell.  But I want
something analogous to ordinary command execution in rule bodies,
rather than something analagous to `$(shell ...)'.
If `$(dynload ...)' was analagous to $(shell ...)',
then using

   CC := $(dynload $(shell gcc -print-dynamic-driver))

wouldn't work, because it would call the dynamically loaded
function when CC was being defined rather than when $(CC) was being used.
Using

        CCDRIVER := $(shell gcc -print-dynamic-driver)
        CC = $(dynload CCDRIVER)

        foo.o: foo.c
                $(CC) -c foo.c
i.e.

        foo.o: foo.c
                $(dynload $(CCDRIVER)) -c foo.c

wouldn't quite work either, even though it would call the function
each time $(CC) was used, because it wouldn't pass any command arguments.
To make it work right (and be consistent with the other $(...) functions),
the arguments would have to be specified inside the $(dynload ...).
Also you'd need some way of propagating the command return value.
So to make it work you'd need to write something like

        foo.o: foo.c
                exit $(dynload $(CCDRIVER) -c foo.c)

And doing that would mean you'd have to have to modify your existing Makefiles
dramatically to make them work with dynamic loading, and making them work
both with and without dynamic loading depending on whether or not it was
available would be complicated.

And if `$(dynload ...)' *wasn't* analagous to `$(shell ...)',
but instead looked at whatever else was on the command line
*after* the matching ')', then it would be inconsistent and confusing.

-- 
Fergus Henderson <address@hidden>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.