[Top][All Lists]

[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

From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master 210257a 7/9: Source a script in a makefile
Date: Fri, 24 May 2019 13:58:03 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 2019-05-22 16:50, Vadim Zeitlin wrote:
>  To make this even more concrete, here is a simple patch which seems to
> work for me:

[...drastically trimmed...]

> -       . ./set.sh ; \
> +       ./set.sh > $@ ; \
> -export LMI_OUT1="$LMI_IN"
> -export LMI_OUT2="$LANG"
> +echo export LMI_OUT1="$LMI_IN"
> +echo export LMI_OUT2="$LMI_OUT2"

This is about the same as what the GNU make maintainer suggested here:

There are three use cases for this script, to export variables...
 (A) in a single top-level makefile only
 (B) in several other scripts (and probably more in the future)
 (C) at the command line (frequently)

The proposed change would simplify the way (A) is done. But (A) is done
once and only once, so simplifying it slightly has little benefit. And
it would require us to change the way (B) is done. For example, to add
a new 'script.sh' to the patch, we'd have to write something like:

eval $(./set.sh)
echo "'$LMI_IN' --> '$LMI_OUT1', '$LMI_OUT2' : eval in 'script.sh'"

and (C) would have to change similarly. That's not a lot more to type,
but it's dangerous. With a bad command in a script, eval(1) can be a
disaster, but $(eval include) will probably be a syntax error. It seems
like a mistake to optimize (A) at the cost of pessimizing (B) and (C).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]