[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sub-make environment
Too, Justin A.
Re: Sub-make environment
Sat, 16 Apr 2011 09:35:17 -0700
On 4/16/11 3:17 AM, "Stefano Lattarini" <address@hidden>
>On Friday 15 April 2011, Justin wrote:
>> Hi all,
>> 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
> $ make # this is GNU make
>For more info, see:
>> 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
>You can use the TESTS_ENVIRONMENT 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.
> 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 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:
809 as Ralf mentioned; which adds nicely to this discussion.)