Makefile help: setting HOTSPOT_EXTRA_SYSDEFS
David.Holmes at oracle.com
Wed Jun 16 01:42:55 UTC 2010
Martin Buchholz said the following on 06/16/10 11:39:
> I'm pasting in the relevant section from the GNU make manual,
> hoping it helps.
Thanks but no - I've read all that and I'm exporting the variables, but
it isn't working as I desire.
I wish there was a Make equivalent of "sh -x" to really see what it is
doing with the variable definitions etc. :(
> 5.7.2 Communicating Variables to a Sub-`make'
> Variable values of the top-level `make' can be passed to the sub-`make'
> through the environment by explicit request. These variables are
> defined in the sub-`make' as defaults, but do not override what is
> specified in the makefile used by the sub-`make' makefile unless you
> use the `-e' switch (*note Summary of Options: Options Summary.).
> To pass down, or "export", a variable, `make' adds the variable and
> its value to the environment for running each command. The sub-`make',
> in turn, uses the environment to initialize its table of variable
> values. *Note Variables from the Environment: Environment.
> Except by explicit request, `make' exports a variable only if it is
> either defined in the environment initially or set on the command line,
> and if its name consists only of letters, numbers, and underscores.
> Some shells cannot cope with environment variable names consisting of
> characters other than letters, numbers, and underscores.
> The value of the `make' variable `SHELL' is not exported. Instead,
> the value of the `SHELL' variable from the invoking environment is
> passed to the sub-`make'. You can force `make' to export its value for
> `SHELL' by using the `export' directive, described below. *Note
> Choosing the Shell::.
> The special variable `MAKEFLAGS' is always exported (unless you
> unexport it). `MAKEFILES' is exported if you set it to anything.
> `make' automatically passes down variable values that were defined
> on the command line, by putting them in the `MAKEFLAGS' variable.
> *Note Options/Recursion::.
> Variables are _not_ normally passed down if they were created by
> default by `make' (*note Variables Used by Implicit Rules: Implicit
> Variables.). The sub-`make' will define these for itself.
> If you want to export specific variables to a sub-`make', use the
> `export' directive, like this:
> export VARIABLE ...
> If you want to _prevent_ a variable from being exported, use the
> `unexport' directive, like this:
> unexport VARIABLE ...
> In both of these forms, the arguments to `export' and `unexport' are
> expanded, and so could be variables or functions which expand to a
> (list of) variable names to be (un)exported.
> As a convenience, you can define a variable and export it at the same
> time by doing:
> export VARIABLE = value
> has the same result as:
> VARIABLE = value
> export VARIABLE
> export VARIABLE := value
> has the same result as:
> VARIABLE := value
> export VARIABLE
> export VARIABLE += value
> is just like:
> VARIABLE += value
> export VARIABLE
> *Note Appending More Text to Variables: Appending.
> You may notice that the `export' and `unexport' directives work in
> `make' in the same way they work in the shell, `sh'.
> If you want all variables to be exported by default, you can use
> `export' by itself:
> This tells `make' that variables which are not explicitly mentioned in
> an `export' or `unexport' directive should be exported. Any variable
> given in an `unexport' directive will still _not_ be exported. If you
> use `export' by itself to export variables by default, variables whose
> names contain characters other than alphanumerics and underscores will
> not be exported unless specifically mentioned in an `export' directive.
> The behavior elicited by an `export' directive by itself was the
> default in older versions of GNU `make'. If your makefiles depend on
> this behavior and you want to be compatible with old versions of
> `make', you can write a rule for the special target
> `.EXPORT_ALL_VARIABLES' instead of using the `export' directive. This
> will be ignored by old `make's, while the `export' directive will cause
> a syntax error.
> Likewise, you can use `unexport' by itself to tell `make' _not_ to
> export variables by default. Since this is the default behavior, you
> would only need to do this if `export' had been used by itself earlier
> (in an included makefile, perhaps). You *cannot* use `export' and
> `unexport' by themselves to have variables exported for some commands
> and not for others. The last `export' or `unexport' directive that
> appears by itself determines the behavior for the entire run of `make'.
> As a special feature, the variable `MAKELEVEL' is changed when it is
> passed down from level to level. This variable's value is a string
> which is the depth of the level as a decimal number. The value is `0'
> for the top-level `make'; `1' for a sub-`make', `2' for a
> sub-sub-`make', and so on. The incrementation happens when `make' sets
> up the environment for a command.
> The main use of `MAKELEVEL' is to test it in a conditional directive
> (*note Conditional Parts of Makefiles: Conditionals.); this way you can
> write a makefile that behaves one way if run recursively and another
> way if run directly by you.
> You can use the variable `MAKEFILES' to cause all sub-`make'
> commands to use additional makefiles. The value of `MAKEFILES' is a
> whitespace-separated list of file names. This variable, if defined in
> the outer-level makefile, is passed down through the environment; then
> it serves as a list of extra makefiles for the sub-`make' to read
> before the usual or specified ones. *Note The Variable `MAKEFILES':
> MAKEFILES Variable.
> On Tue, Jun 15, 2010 at 18:27, David Holmes <David.Holmes at oracle.com> wrote:
>> I originally asked this internally to my HS colleagues but alas no solution.
>> Any Make gurus out there? ;-)
>> A further note: the obvious reason for this to fail would be because
>> defs.make is not processed before launching the buildtree.make sub-make, but
>> AFAICS it is processed.
>> David Holmes said the following on 06/15/10 19:14:
>>> If I set HOTSPOT_EXTRA_SYSDEFS in the environment or pass it as a variable
>>> to the top-level make invocation then it works fine and buildtree.make will
>>> see it and use it in the makefiles that it generates.
>>> However, I want to set it in the top-level defs.make based on some other
>>> values. I do that and export it so that submakes will see it - but they
>>> don't: buildtree.make sees HOTSPOT_EXTRA_SYSDEFS as empty.
>>> I've tried setting it using += and := but they both fail to set it for the
>>> Using "make -d" is no help at all as it doesn't show how it evaluates
>>> things (the way sh -x does). :(
>>> Does anybody know how I can set this?
More information about the build-dev