Re: [lmi] [lmi-commits] master 210257a 7/9: Source a script in a makefile

[Vadim Zeitlin]

On Fri, 24 May 2019 13:58:03 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-05-22 16:50, Vadim Zeitlin wrote:
GC> [...]
GC> >  To make this even more concrete, here is a simple patch which seems to
GC> > work for me:
GC> 
GC> [...drastically trimmed...]
GC> 
GC> >  $(LMI_ENV_FILE):
GC> > -       . ./set.sh ; \
GC> > +       ./set.sh > $@ ; \
GC> ...
GC> > -export LMI_OUT1="$LMI_IN"
GC> > -export LMI_OUT2="$LANG"
GC> ...
GC> > +echo export LMI_OUT1="$LMI_IN"
GC> > +echo export LMI_OUT2="$LMI_OUT2"
GC> 
GC> This is about the same as what the GNU make maintainer suggested here:
GC>   https://lists.gnu.org/archive/html/help-make/2006-04/msg00142.html
GC> 
GC> There are three use cases for this script, to export variables...
GC>  (A) in a single top-level makefile only
GC>  (B) in several other scripts (and probably more in the future)
GC>  (C) at the command line (frequently)
GC> 
GC> The proposed change would simplify the way (A) is done.

 At least as importantly, it would simplify the script itself.

GC> But (A) is done once and only once, so simplifying it slightly has
GC> little benefit. And it would require us to change the way (B) is done.
GC> For example, to add a new 'script.sh' to the patch, we'd have to write
GC> something like:
GC> 
GC> #!/bin/sh
GC> eval $(./set.sh)
GC> echo "'$LMI_IN' --> '$LMI_OUT1', '$LMI_OUT2' : eval in 'script.sh'"
GC> 
GC> and (C) would have to change similarly. That's not a lot more to type,
GC> but it's dangerous. With a bad command in a script, eval(1) can be a
GC> disaster, but $(eval include) will probably be a syntax error. It seems
GC> like a mistake to optimize (A) at the cost of pessimizing (B) and (C).

 As I wrote before, we could keep set.sh with just "eval $(./echo-set.sh)"
inside it if you really prefer "." to "eval". I actually prefer the latter
to the former because it's simpler to see what is being evaluated by
running echo-set.sh first without eval and looking at its output, rather
than studying set.sh code to see what it does. But by having both set.sh
and echo-set.sh you could have the best of both worlds and still keep
things as simple as possible.

 Regards,
VZ