[ENH] Paths handling

Currently the handing of filesystem paths is not quite optimal:

  • Handling is dispatched on two commands: get_filename_component and file
  • get_filename_component is a bit counterintuitive because it is used for operations other than extracting component from filename
  • Some basic capabilities are not available (see #19568)

Moreover, it is not clear which operations require filesystem access or not. And even more curious, get_filename_component can be used to read the Windows registry (not documented).

So, I propose to introduce the new command cmake_path to manage all operations on path not requiring filesystem access (same semantic as std::filesystem::path C++ class) and use file command for operations requiring filesystem access (so get_filename_component(REALPATH) should be offered as part of file).

For the command name, path should be nice, but I am afraid that it is no longer possible to introduce a such name without creating conflicts with existing user’s code. And, anyway, the goal is not handle paths in CMake format…

For the possible operations of cmake_path, I propose to follow what is offered by std::filesystem::path with a CMake twist of course :slight_smile:

And for Windows registry access, may be a dedicated command should be fine. Or a module relying on reg windows command should be fine as well.

@brad.king, @craig.scott, @kyle.edwards Comments welcome.

Cc: @ben.boeckel

It would be great to clean up and formalize filesystem operations both internally and in the CMake language. However, the old path “translation map” may get in the way and should probably be handled first. See CMake Issue 16228.