On 21 August 2007 13:39, Paul Smith wrote:
> On Mon, 2007-08-20 at 18:59 +0100, Dave Korn wrote:
>> As discussed last week, and ported to CVS head from our own internal
>> build over the weekend, here's a patch that implements verbatim export
>> of makefile variables to subprocesses. This is particularly handy for
>> anything with a dollar sign in it!
>
> I'll have to think about this; it seems like a lot of change for
> something that very few people have ever asked for. Also, there are at
> least two ways to share variable values with other instances of make
> that I don't think have the issue you're having: one is to pass the
> value via the command line instead of through the environment (where you
> can use $(value ...)) and the other is to put it into a makefile that is
> included by the different instances of make.
>
> What do you think about those?
Both valid, but I think they're less convenient. With the first method, you
either have to enumerate all the functions explicitly, or follow a naming
convention that lets you grep them out of .VARIABLES and automatically add them
to the submake command line. You're also likely to run into shell quoting
complications. I would have said that big command lines are a problem in
themselves, but then again I think on most systems there's a limit on the total
of (commandline length + environment size) anyway, so that's no different.
The second one works too, but in my case I didn't want to hard-code an
explicit
full or relative path to the library file, because I don't want stuff lower in
the hierarchy to know about what's going on further up. For my money, the ideal
solution was for the top-level makefile to include the library, and for it to
then be available to everything below. I expected export to do this for me and
found it not in accordance with my particular definition of least surprise when
the exported functions ended up in the submake but were mangled! After all,
when
you use export in a shell, what you see in the sub-shell is exactly what you
exported.
It's subjective of course, but speaking as someone who does an awful lot of
maintenance programming myself, I think the patch isn't really "a lot of
change".
I added a stanza in snap_deps that follows an existing pattern and is obviously
correct. I added a third state to export_all_vars and ensured I fixed every
reference. I added "or verbatim" to the condition that detects the export
directive and a simple ternary operator to the assignments. Most of this is
mechanical. The only tricky bit is the evaluation of do_verbose I think, and I
think it's right the way I've written it. I'm pretty sure that in the absence
of
the verbatim keyword, the existing behaviour is exactly preserved, and I don't
think the syntax is terribly likely to clash with anyone's existing makefiles (I
know you *can* have variable names like 'vebatim<SPACE>foo', but I bet it
doesn't
happen much in practice).
It's a nice feature, it fits very well with what make already does and makes
it
more orthogonal and complete, it facilitates good architecture and style, and it
matches the intuitive expectations that anyone from a posix background will have
about what it means to export a variable. I'd already written the code for my
own internal purposes so it was no trouble to offer it back upstream - and it's
always nice to avoid forks, in general.
Any of the lurkers round here have opinions?
cheers,
DaveK
--
Can't think of a witty .sigline today....
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
