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

[Greg Chicares]

Let me begin with a patch that I think represents what you would recommend:

---------8<--------8<--------8<--------8<--------8<--------8<--------8<-------
diff --git a/gwc/parent.make b/gwc/parent.make
index 81fd3eb3..37780e94 100644
--- a/gwc/parent.make
+++ b/gwc/parent.make
@@ -22,8 +22,12 @@ parent.make:: $(LMI_ENV_FILE)
        rm $(LMI_ENV_FILE)
 
 $(LMI_ENV_FILE):
-       @echo "Sourcing 'set.sh'"; \
-       . ./set.sh ; \
+       @echo "Sourcing 'set.sh'"
+       @. ./set.sh ; \
+         { \
+           echo "export LMI_OUT1 := $$LMI_OUT1"; \
+           echo "export LMI_OUT2 := $$LMI_OUT2"; \
+         } > $@ ; \
        echo "'$$LMI_IN' --> '$$LMI_OUT1', '$$LMI_OUT2' : sourced in 
'parent.make'"
 
 all:
diff --git a/gwc/set.sh b/gwc/set.sh
index 0660dc91..4367d492 100755
--- a/gwc/set.sh
+++ b/gwc/set.sh
@@ -16,12 +16,6 @@ case "$LMI_IN" in
 esac
 
 echo "'$LMI_IN' --> '$LMI_OUT1', '$LMI_OUT2' : leaving 'set.sh'"
-if [ -n "$LMI_ENV_FILE" ]; then
-    {
-    echo "export LMI_OUT1 := $LMI_OUT1"
-    echo "export LMI_OUT2 := $LMI_OUT2"
-    } > "$LMI_ENV_FILE"
-fi
 }
 
 foo
--------->8-------->8-------->8-------->8-------->8-------->8-------->8-------

...and then reply in detail:

On 2019-05-20 15:41, Vadim Zeitlin wrote:
> 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> +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)

I think your objection is mainly to commit 315d415d, discussed below.
In increasing chronological order:
  315d415d 2019-05-17T15:58Z Improve encapsulation
  210257ae 2019-05-18T17:12Z Source a script in a makefile
If we like 315d415d, then I think 210257ae is appropriate. I.e., if
LMI_ENV_FILE is null or unset, then indeed nothing is written to the
file it names, and that's exactly the desired behavior.

But maybe we shouldn't like 315d415d. Its commit message says:

| The list of environment variables may change over time. Maintenance is
| easier if this list appears in one file rather than two.
|
| It is also nicer to write shell code in scripts than in makefiles where
| dollar signs must be doubled.

and it did essentially this, simplified for this discussion:

[makefile]
  $(eval include env.make) # in recipe to remake top-level makefile
  $(TEMPORARY_FILE):
- . ./set.sh ; \
-   echo "export LMI_OUT1 := $$LMI_OUT1" > $(TEMPORARY_FILE)
+ . ./set.sh

[script]
+ echo "export LMI_OUT1 := $LMI_OUT1" > $TEMPORARY_FILE

so the question is: where should the 'make' assignments be written?
In one place only, because one is better than two, ceteris paribus?
Or...

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

I think you're saying that, despite the advantages claimed for
maintaining the list of variables in one place only, it seems
better to make the sourceable script do one and only one thing,
and have the makefile do whatever's necessary to use the shell
environment variables set by the script.

Is that what you're saying? And would the patch above address
your concerns? I'm on the fence, but I'll commit that patch if
you prefer it--I just wanted to make sure we consider it from
all sides.