Re: suppressing $ resolution in variable value

[Kaz Kylheku (gmake)]

On 2021-09-02 09:14, David Boyce wrote:
> I found this an interesting problem so took a little time from the day 
> job
> to look into it. There are a number of issues here. First, not directly
> related but environment variables are supposed to be uppercase by
> convention though it's not enforced.

Hi David,

This common belief about environment variables (entrenched in actual
practice) turns out to be surprisingly erroneous.

POSIX says that all upper-case environment variables are effectively
reserved.

Conforming applications (such as shell scripts, Makefiles, C programs
and everything else) should use names which contain lower case letters.

This is documented here, in Chapter 8, Environment Variables:

https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap08.html

"Environment variable names used by the utilities in the Shell and 
Utilities
volume of POSIX.1-2017 consist solely of uppercase letters, digits, and 
the
<underscore> ( '_' ) from the characters defined in Portable Character 
Set
and do not begin with a digit. Other characters may be permitted by an
implementation; applications shall tolerate the presence of such names.
Uppercase and lowercase letters shall retain their unique identities
and shall not be folded together. The name space of environment variable
names containing lowercase letters is reserved for applications.
Applications can define any environment variables with names from this
name space without modifying the behavior of the standard utilities.

(By the way that "applications shall tolerate the presence of such 
names"
strikes home to me: I had to debug an obscure problem in some build 
script
that processed the entire contents of env, and made bad assumptions 
about
what variable names can look like.)

> Even when a variable is passed on the
> command line it's supposed to be uppercase according to the manual "How 
> To
> Use Variables".

Yes, I see the text:

"It is traditional to use upper case letters in variable names, but we
recommend using lower case letters for variable names that serve 
internal
purposes in the makefile, and reserving upper case for parameters that
control implicit rules or for parameters that the user should override
with command options (see Overriding Variables).

That's a bit of a defect in the manual which should be harmonized with
the standardization facts.  It does describe a widespread practice,
to be sure.

Also, we should look at the POSIX description of make:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

doesn't say anything about reserved name spaces. It describes a default
rule set which provides some variables like CC, AR, YACC and others.

It says that the implementation can extend this set of variables.

Nowhere does it say in which namespace; there is no such discussion.
But if we read between the lines from what we know about the environment
variable requirements, I think that make implementations are supposed
to use this ALL_CAPS namespace for any such additional variables.
That and the fact that make variables can pick up values from the
environment adds up to a good case for treating this namespace as
reserved, in the same way as the environment namespace.

E.g. if you're writing the buildsystem for some FooBar program and
would like the user to be able to specify additional compilation
flags that get added to CFLAGS, it may be wise to call this variable
foobar_extra_CFLAGS rather than FOOBAR_EXTRA_CFLAGS.

Ultimately the choice is up to the users. Intruding into a reserved
namespace is not a problem /per se/; it just creates the abstract
risk of a clash. The specific shape of the identifier matters; e.g.
it's vanishingly unlikely that FOOBAR_EXTRA_CFLAGS would ever clash
with anything in the system.

The manual for GNU Make should probably give the straight dope, though,
from both angles.