Re: export vs $(origin )

[Jan Beulich]

On 02.07.2020 17:31, Paul Smith wrote:
> On Thu, 2020-07-02 at 17:16 +0200, Jan Beulich wrote:
>>> export wom
>>> introduces the variable to the env and set origin to environment.
>>
>> Not according to my observations.
> 
> The difference is whether the variable already exists in the
> environment or not.
> 
> For this makefile:
> 
>   export FOO
>   $(info FOO: $(origin FOO))
>   all:;
> 
> If you run it like this:
> 
>   $ FOO= make
>   FOO: environment
>   make: 'all' is up to date.
> 
> But if you run it like this:
> 
>   $ unset FOO; make
>   FOO: file
>   make: 'all' is up to date.
> 
> Basically, if you run "export FOO" and FOO does not currently exist at
> all, either in the environment or in the makefile, then it's created in
> make and assigned a "file" origin.
> 
> I'm not sure how it could be otherwise: by specifying "export" you ARE
> creating that variable, because it will be placed into the child's
> environment when a recipe is invoked, even if it's not set.  In other
> words, if FOO is not already a variable make knows about then running
> "export FOO" makes it into a variable that make knows about, which has
> its "export" flag set.
> 
> For example if you change the above makefile:
> 
>   export FOO
>   $(info FOO: $(origin FOO))
>   all: ; @env | grep FOO
> 
> then you run:
> 
>   $ unset FOO; make
>   FOO: file
>   FOO=
>   make: 'all' is up to date.
> 
> you can see that "FOO" is in the environment in the recipe even though
> it wasn't in the environment when make started.

Well, okay, if this behavior is intentional, then may I ask that
the documentation be adjusted to clarify this behavior (i.e. it
is not just a convenience that the variables _can_ be assigned a
value, but instead they always _will_ be assigned one, potentially
empty)? In the case having triggered this report, it has taken me
half a day to wade through makefiles, further complicated by some
non-standard way of recursing as well as the underlying problem
really triggering only on an older version (3.82 in the specific
case) related to how -r and -R get handled when appended to
MAKEFLAGS in a makefile, and when some of the included makefiles
gets remade and hence a re-invocation of make gets triggered.

Also, if this is intentional, then I suppose there is no solution
to the problem I'm having except moving the export line(s) until
after the variable(s) have been assigned to (or moving the
$(origin ) checks ahead of the export, which in my specific case
is not really possible).

As an aside, I am still unconvinced the behavior you describe is
the only one possibly sensible. I could as well view "export" as
a directive to indicate to put the given variable(s) into the
environment, but only if they've been assigned a (potentially
empty) value. I.e. these two would then have different behavior:

export XYZ
export XYZ=

Which means the current behavior could be achieved for people
wanting it, while export wouldn't unconditionally have the effect
of also defining the variable(s) (i.e. more along the lines of
what current documentation says).

Thanks again, Jan