[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] [lmi-commits] master 210257a 7/9: Source a script in a makefil
Re: [lmi] [lmi-commits] master 210257a 7/9: Source a script in a makefile
Fri, 24 May 2019 18:00:59 +0200
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> > To make this even more concrete, here is a simple patch which seems to
GC> > work for me:
GC> [...drastically trimmed...]
GC> > $(LMI_ENV_FILE):
GC> > - . ./set.sh ; \
GC> > + ./set.sh > $@ ; \
GC> > -export LMI_OUT1="$LMI_IN"
GC> > -export LMI_OUT2="$LANG"
GC> > +echo export LMI_OUT1="$LMI_IN"
GC> > +echo export LMI_OUT2="$LMI_OUT2"
GC> This is about the same as what the GNU make maintainer suggested here:
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> 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> eval $(./set.sh)
GC> echo "'$LMI_IN' --> '$LMI_OUT1', '$LMI_OUT2' : eval in 'script.sh'"
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.