Linux relative and absolute path concat

Sysprogs forums Forums VisualGDB Linux relative and absolute path concat

This topic contains 1 reply, has 2 voices, and was last updated by  support 1 month, 2 weeks ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #28197

    ishmakov
    Participant

    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.

    #28198

    support
    Keymaster

    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.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.