[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Variable export, recursion, and environment
From: |
Sankaranarayanan K V |
Subject: |
Re: Variable export, recursion, and environment |
Date: |
Thu, 19 Oct 2000 13:05:44 +0530 |
User-agent: |
Mutt/1.2i |
On Mon, Oct 16, 2000 at 04:40:20PM -0400, Paul D. Smith wrote:
> %% Sankaranarayanan K V <address@hidden> writes:
>
> skv> Case 1:
>
> skv> 1. The environment does NOT have a variable VAR set.
> skv> 2. The top level Makefile does NOT export VAR.
> skv> 3. The top level Makefile sets VAR to x.
>
> skv> Result: The sub-make invocation does NOT inherit a value for VAR.
>
> Yes.
>
> skv> Case 2:
>
> skv> Same as Case (1) except that the environment defines VAR=y.
>
> skv> Result: The sub-make invocation inherits a value for VAR.
> skv> But the value is x (set by the parent Makefile) and not y.
>
> Yes.
>
> skv> Somehow, this seems a bit strange to me.
> skv> What is the rationale behind such a behaviour?
>
> You should check the GNU make manual section "Variables from the
> Environment" to see how make handles this.
>
> skv> I would expect make to either pass the environment value
> skv> _or_ not to pass any value at all to the sub-make.
>
> You're not thinking of this correctly. Make uses variables the same way
> the shell does, basically. Variables that are obtained from the parent
> process are considered "exported" and passed to any sub-processes, but
> any value changes that happen in the current process are also
> exported.
This behaviour is not the same for different shells:
- bash behaves just as you have said --
it passes on changes to the child even if the variable is not
exported specifically in the parent.
- sh (the Bourne shell) does NOT pass the changes to the child if the
variable is not exported.
Now, isn't that strange? What does POSIX say?
BTW, I am on a Solaris 2.5.1. I am using bash 1.14.3(1).
>
> You would find it darn strange if you changed the value of a variable in
> the shell, but any subshells got the _previous_ value and not the new
> one... well, make handles these the same way.
Regards
Sankar
--
Sankaranarayanan K. V. | address@hidden
Motorola India Electronics Ltd | http://www.mot.com/miel