Re: Sub-make environment

[Too, Justin A.]

On 4/16/11 3:17 AM, "Stefano Lattarini" <address@hidden>
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