- This topic has 1 reply, 2 voices, and was last updated 4 years, 6 months ago by
.
-
Posts
-
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.
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.
- You must be logged in to reply to this topic.