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
