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

[Greg Chicares]

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...]

>  $(LMI_ENV_FILE):
> -       . ./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:
  https://lists.gnu.org/archive/html/help-make/2006-04/msg00142.html

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:

#!/bin/sh
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).