Running cmake -E env NAME="" <program> gives different behavior when running on Linux vs Windows.
On Linux (what I’m used too) the environment variables is defined and contains an empty string, but on Windows the environment variable become undefined/deleted. In my case this is problematic as the third-party python script [1] that I use, has different behavior between when an environment variable is undefined or defined as a empty string.
The normal legacy behavior on Windows seems to be that the environment variable should be deleted when assigned to an empty string, however since .NET 9, this behavior has been changed [2].
My suggestion is to either change the behavior to allow empty environment variables or add a new option to allow it.
My understanding is that Windows doesn’t differentiate between an empty environment variable and an undefined environment variable. I believe setting an environment variable to an empty string is effectively the same as making it undefined. This has come up in a few other places from time to time, and I’m just relaying that information here. I don’t know the details or whether there has been a change in that behavior recently.
And I realize my suggestion is just doing what the current behavior is, so it isn’t actually helpful. Alas, CMake is using the system APIs to set environment variables; I wonder if CMake needs to adapt and call the routines documented in [2] instead of the current ones?
I am afraid that behavior is only available in .NET because it seems that environment variables are managed in the .NET process, not the OS itself.
Anyway, currently, CMake does not use .NET at all.
Ah. Well, that is quite unfortunate that there is now “yes, we support empty string envvar values” with the unstated subtext of “but executed processes will still see them as undefined”. In-process envvar communication is a horrible practice…why support something only good for that? But oh well.