Re: Sub-make environment

[Stefano Lattarini]

On Friday 15 April 2011, Justin  wrote:
> Hi all,
>
Hello Justin.
 
> I'm trying to communicate environment variables to a sub-make.
> I'm aware of the Make 'export' directive,
>
Note that this is GNU make specific.  It won't work with e.g. BSD make
or Solaris make.

> but this just creates a Makefile variable in a Sub-make, right?
>
No, it exports the variable in the environment of all the recipes (and
thus, in particular, of sub-make invocations also); for example:
  $ cat > Makefile <<'END'
  FOOBAR = zardoz
  export FOOBAR
  all:; @env | grep ^FOOBAR && echo FOOBAR=$$FOOBAR
  END
  $ make # this is GNU make
  FOOBAR=zardoz
  FOOBAR=zardoz

For more info, see:
 
<http://www.gnu.org/software/make/manual/html_node/Variables_002fRecursion.html>
 <http://www.gnu.org/software/make/manual/html_node/Environment.html>

> I would like a Sub-make to have the same shell PYTHONPATH and CLASSPATH
> environment variables set, for example.
>
If you are requiring GNU make, you could use the export directive; but
note that this will make the values of PYTHONPATH and CLASSPATH available
not only to the test scripts, but also to the environment of all recipes
in your Makefile.  This might be undesirable.

> I'm using an executable that is generated during 'make' to run tests
> during 'make check' and this executable requires certain environment
> variables to be set (that point to paths generated during 'make').
> If I could set these things at the top-level 'make check', that would
> be great.  For now, I created a wrapper for the executable that
> basically does the necessary environment setup and then runs the
> executable.
>
You can use the TESTS_ENVIRONMENT[1] variable to define and export
all the required variables to your test scripts (see the automake
manual for more info).  Still, note that this solution will have
the side effect of exporting the required variables not only to
your executable, but to the test scripts as a whole, and this might
be undesirable in some situations.  Also, your current solution of
using a wrapper script is employed in the Automake's own testsuite,
so if it works you might want to just stick with it.

[1] Adimittedly, the name of this variable is poorly chosen, because
    it invades the user's name space; future version of automake will
    offer better alternatives.

> Thanks,
> Justin
> 

HTH,
  Stefano