Linux relative and absolute path concat

[ishmakov]

Hello.

I see an problem with working with relative and absolute path concat. I see that VisualGDB use plus two path, for example

I set

CMake directory: /mnt/hgfs/git/master/build/app1 (this is absolute path)

Binary directory: /mnt/hgfs/git/master/build/app1 (this is absolute path)

As result:
$TargetPath=/mnt/hgfs/git/master/build/app1/mnt/hgfs/git/master/build/app1

$(CMakeConfigurationDir)=/mnt/hgfs/git/master/build/app1/mnt/hgfs/git/master/build/app1

But should be:
$TargetPath=/mnt/hgfs/git/master/build/
$(CMakeConfigurationDir)=/mnt/hgfs/git/master/build/app1/

The same problem with relative path:

Binary directory: ../build/app1 (this is relative path)

$TargetPath=/mnt/hgfs/git/master/../build/app1
$(CMakeConfigurationDir)=/mnt/hgfs/git/master/../build/app1
This is good for CMake, but when make works with paths with .., this fail and don’t understand.

Good will be

$TargetPath=/mnt/hgfs/git/build/app1

You can implimant path concat with std::filesystem::path from C++17, that really right work with two relative and absoult paths.

[support]

Hi,

This behavior happens because VisualGDB builds the target path template before it expands all variables (i.e. it would be internally defined as $(BuildDir)/../build/app1 and $(BuildDir) will get expanded later).

Normally, using the relative path syntax (“../build/app1”) should work. We have tested it with both GNU Make and Ninja and it worked as expected (the /mnt/hgfs/git/master/../build/app1 path does look awkward, but it should not cause any problems).

If it doesn’t work due to some project-specific tools, we can add a variable syntax that will resolve the “..” in paths (i.e. you would need to use something like $(TargetPath.fullpath)). Would that work for you?

Alternatively, please consider using the Advanced CMake Project Subsystem. It sets the $(TargetPath) variable based on the path reported by CMake, and that path is usually fully resolved.

[Author]

Posts