On 4/16/11 3:17 AM, "Stefano Lattarini" <stefano.lattar...@gmail.com> wrote:
>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 Thanks for the good tips Stefano, I'm sure these things will come in handy next time -- for now, I may just stick to my wrapper script. (I did ask a similar question before: http://thread.gmane.org/gmane.comp.sysutils.automake.general/12808/focus=12 809 as Ralf mentioned; which adds nicely to this discussion.) Thanks again, Justin
