1.9.0rc1 regression: `exe.full_path()` uses forward slashes on Windows

[bgilbert]

Describe the bug
On Windows, the string returned by exe.full_path() uses forward slashes as the path separator.

In particular, this breaks WrapDB subprojects using meson.override_find_program() (e.g. in mesonbuild/wrapdb#2311) because WrapDB expects overridden paths to start with meson.global_source_root() or meson.global_build_root(), both of which use backslashes.

To Reproduce

project('dnm', 'c')
exe = executable('dnm', 'dnm.c')
message(exe.full_path())

Expected behavior
The returned path uses backslashes as the path separator, as it did in Meson 1.8.0. full_path() is typically used in cases where the exact format of the string matters, since it's about to be passed to tools outside Meson's control.

system parameters

• Is this a cross build or just a plain native build (for the same computer)?

native

• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.)

Windows Server 2022

• what Python version are you using e.g. 3.8.0

3.9.13

• what meson --version

1.9.0.rc1

• what ninja --version if it's a Ninja build

1.13.1

[bonzini]

Could you bisect this? (And if so, thanks in advance! :)

[bgilbert]

Yes: 12563f7 is the first bad commit.

cc @amyspark

[bonzini]

A related question then is why don't meson.global_build_root() and friends use forward slashes (and whether they should) but reverting is probably safest for 1.9.

…

Message ID: ***@***.***>

[eli-schwartz]

Honestly using forward slashes on its own would be less of a problem, if not for the fact that the DSL now exposes it inconsistently -- some paths are forward ones, others are backward ones.

In many contexts we know a forward slash version is supported -- especially when directly interacting with compilers where we control the arguments. The situation is very different from DSL return values. It's much safer to do the transformation in the backend.

A related question then is why don't meson.global_build_root() and friends use forward slashes (and whether they should) but reverting is probably safest for 1.9.

It is certainly something I've thought of before, yes. But the simple answer is because only some call sites for "storing paths of some sort" were converted in the linked commit to use as_posix(), and they were all things containing relative paths.

[dnicolodi]

We bumped into problems with the change of backward to forward slashes in meson-python too: mesonbuild/meson-python#747 (comment), mesonbuild/meson-python#778, mesonbuild/meson-python#785

[joukewitteveen]

This reminds me of the fact that we also have two methods of escaping shell arguments. It seems to be okay at the moment, but I think we could really use an explicit statement on what the guiding principles (a 'philosophy' if you will) regarding dealing with the peculiarities of Windows are.

[lb90]

BTW, find_program('cmd') has a mixture of forward and backward slashes:

Program cmd found: YES (C:\Windows\System32/cmd.EXE)

[amyspark]

cc @nirbheek -- There are 1.7k instances of os.path.join in the source code, and I think his approach would be insightful here, as we changed that to have consistency in the directory separators.

[bonzini]

What to do here? Revert, document or change the meson object to use forward paths (and hope no other regressions creep in)?

[bgilbert]

Projects are likely to embed the full_path() return value e.g. in #defines, so changing its format is a breaking change.

[bonzini]

Fixed by #14922.