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

[Vadim Zeitlin]

On Sat, 18 May 2019 14:50:02 -0400 (EDT) Greg Chicares <address@hidden> wrote:

GC> branch: master
GC> commit 210257aee9f89d99c270e494f8122837e3e10d21
GC> Author: Gregory W. Chicares <address@hidden>
GC> Commit: Gregory W. Chicares <address@hidden>
GC> 
GC>     Source a script in a makefile
[...]
GC> diff --git a/GNUmakefile b/GNUmakefile
GC> index 9c56108..1f143f7 100644
GC> --- a/GNUmakefile
GC> +++ b/GNUmakefile
GC> @@ -134,11 +134,15 @@ touchstone_dir  := $(prefix)/touchstone
GC>  
GC>  # Remake this file to "source" a script.
GC>  
GC> -GNUmakefile $(srcdir)/GNUmakefile:: source_env_vars ;
GC> +export LMI_ENV_FILE := env_$(shell date -u +'%s_%N').eraseme
[...]
GC> diff --git a/set_toolchain.sh b/set_toolchain.sh
GC> index 73d3547..319fd17 100755
GC> --- a/set_toolchain.sh
GC> +++ b/set_toolchain.sh
GC> @@ -108,12 +108,9 @@ local  winebindir="$prefix"/third_party/bin
GC>  minimal_path=${MINIMAL_PATH:-"/usr/bin:/bin:/usr/sbin:/sbin"}
GC>  export PATH="$localbindir":"$locallibdir":"$minimal_path"
GC>  
GC> -# It is appropriate to unset $WINEPATH because no lmi script ever uses
GC> -# it directly--it's used, implicitly, only by 'wine'. But $PERFORM is
GC> -# used directly, so it's always exported, even if empty--though that's
GC> -# probably just a matter of taste.
GC> +# It is okay to export these two variables unconditionally.
GC>  
GC> -unset -v WINEPATH
GC> +export WINEPATH
GC>  export PERFORM
GC>  
GC>  # Are double quotes inside double quotes inside $() dubious? I.e.,
GC> @@ -140,6 +137,13 @@ case "$lmi_build_type" in
GC>          ;;
GC>      (*) ;;
GC>  esac
GC> +if [ -n "$LMI_ENV_FILE" ]; then
GC> +    {
GC> +    echo "export PATH     := $PATH"
GC> +    echo "export WINEPATH := $WINEPATH"
GC> +    echo "export PERFORM  := $PERFORM"
GC> +    } > "$LMI_ENV_FILE"
GC> +fi

 I wonder if generating LMI_ENV_FILE as a side effect of execution and only
if LMI_ENV_FILE is defined is a really good idea. IMHO it's a bit fragile
(because nothing silently happens if LMI_ENV_FILE is not defined or has an
unexpected value for whatever reason) and, even more importantly, confusing
to have a file which both exports the variables directly and also echoes
[some of] them and I'd rather prefer the previously mentioned xxx-agent
approach when the script only echoes the variables and its caller
determines what to do with them, whether it's putting them in a file to be
used later or evaluating them immediately.

 If you'd like to still keep a simple to use interactively set_toolchain.sh
we could always refactor it into a non-trivial output_toolchain_defs.sh and
just eval its output from set_toolchain.sh itself.

 What do you think (modulo better name for the new script, as always)?
VZ