[CMake] Possible bug in environment variable expansion?

[David Cole]

OK, I partially take it back, you can set an environment variable that
references other environment variables even through the Windows UI...
But it's a little hard to grasp, because you see it when you're editing
the value, but then when you click OK, the view shows the resolved
value in the result. Combine that with the fact that I nearly always
avoid setting machine-wide env vars, and you can see why I might assert
the type-less-ness of env vars.

But even then, when you inspect the values with "set" or "echo" in a
cmd prompt, there's no evidence of the nested variable, because the
value you get back resolves the contained/nested reference.

The same is true of any other program that calls "getenv" and inspects
values in the environment. Windows resolves the references before it
gets to the program consuming it.

To set a "nested" value via CMake you should use CMake ENV syntax all
the way through, but it will be stored only as a plain old string type
when set via CMake. Plus... any value you set via CMake only takes
effect for the duration of that CMake run.

In other words, your initial attempt to do something like:

    set(ENV{VAR} "%NESTED_VAR%")

should be written as:

    set(ENV{VAR} "$ENV{NESTED_VAR}")

Although, the limited duration of the scope of such a construct makes
it useful only for the duration of running a CMake script, or of the
configure/generate process.

Sorry for the confusion. I could have been more clear in my email this
morning by saying "cross platform programs using environment variables
in a portable way will likely not have an implementation for dealing
with Windows nested environment variables properly..." -- which is
definitely the case for CMake and friends.


HTH,
David C.