Unexpected/Incorrect Path Conversion when Exporting Environment Variables about msys2-runtime

[dscho]

I think you're correct, and this is due to the change where spaces are now considered to be perfectly fine in file/directory names.

I'm not quite sure how we can address your scenario without re-breaking the fix where, say, /c/Program Files was considered not to be a path.

Could you elaborate a bit why the path list in the Makefile has to be in mixed format (i.e. DOS drive but no backslashes) and with a space instead of the usual semicolon as separator?

[cariad-robert-abel]

Could you elaborate a bit why the path list in the Makefile has to be in mixed format (i.e. DOS drive but no backslashes) and with a space instead of the usual semicolon as separator?

The reason I use paths with forward slashes— C:/Project/src instead of C:\Project\src—is that

1. that's the style returned by $(abspath <relative-path>), and
2. sh.exe is in the path and make uses that to invoke recipes, so all backslashes would have to be escaped, which is a nightmare especially when appending to already-escaped variables' contents, and
3. I call native and msys/unixy programs alike and now the translation/escaping of paths would have to be program-specific, which is another headache. Hence the use of mingw32-make instead of regular make.

Why is this list not separated by semi-colons? Because it's actually my INCLUDES variable that is then processed using $(INCLUDES:%=-I%) in the sub-Makefile. It's a regular list of strings separated by whitespace, which is very common in Makefiles. The paths are actually also quoted ("C:/Project/Name/src"), but that does not make a difference to this bug and I left it out for brevity.

I'm not quite sure how we can address your scenario without re-breaking the fix where, say, /c/Program Files was considered not to be a path.

I'm not sure I follow, because wouldn't it have to be /c/Program\ Files anyway in a unixy list of paths, e.g. /c/Program\ Files/Git/bin:/c/Program\ Files/GnuPG/bin? In any case, my use case is really a very common use case when using hierarchical Makefiles, so this will break a lot of use cases, I'm afraid.

I'd be happy if there was a (possibly separate) environment variable that disables this behavior, seeing as even MSYS2_ARG_CONV_EXCL has no effect.

[jeremyd2019]

I'd be happy if there was a (possibly separate) environment variable that disables this behavior, seeing as even MSYS2_ARG_CONV_EXCL has no effect.

I think MSYS2_ENV_CONV_EXCL is what you are looking for here: https://www.msys2.org/docs/filesystem-paths/#environment-variables

That doesn't negate this issue though, this does seem like a common case to me, at least for a user of mingw32-make.

[cariad-robert-abel]

I think MSYS2_ENV_CONV_EXCL is what you are looking for

Wow, I wasn't even aware that msys2 did that. Thanks for pointing this out :)