[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sub-make environment

From: Too, Justin A.
Subject: Re: Sub-make environment
Date: Sat, 16 Apr 2011 09:35:17 -0700
User-agent: Microsoft-MacOutlook/

On 4/16/11 3:17 AM, "Stefano Lattarini" <address@hidden>

>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:
> <>
>> 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
>  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:
809 as Ralf mentioned; which adds nicely to this discussion.)

Thanks again,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]