Sharing *.vgdbsettings between projects, inheriting path from *.vsprops

Sysprogs forums Forums VisualGDB Sharing *.vgdbsettings between projects, inheriting path from *.vsprops

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #7882
    angus_fx
    Participant

    Hello,

    Really enjoying VisualGDB so far. Even got it building Mac binaries thanks to the OSXCross toolchain!

    A couple of issues – we have a big tree of Visual Studio projects. We try to keep as little information as possible in each project file, with them all inheriting from a shared *.vsprops file.

    Problem 1:

    When I try to specify the *.vgdbsettings file name (i.e. NMAKE output) in the common *.vsprops, I get the following:

    1>  Build/launch failed: Missing VisualGDB settings file path
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets(37,5): error MSB3073: The command “”C:\Program Files (x86)\Sysprogs\VisualGDB\\VisualGDB.exe” /build “[…]\projects\win\[…].vcxproj” “/solution:[…]\win\MySolution.sln” “/config:CrossCompileMac” “/platform:Win32″” exited with code 1.

    I’m specifying it as follows:

    <NMakeOutput>$(ProjectDir)$(Configuration).vgdbsettings</NMakeOutput>

    If I specify the exact same information at project level (i.e. in the *.vcxproj instead of in the inherited *.vsprops), it builds correctly.

    So it looks like the VGDB engine may not be parsing all the inherited property sheets correctly to get the correct value for the config-file-name variable.

    Problem 2:

    Ideally, I’d like to have the *.vgdbsettings shared between all my projects, e.g. at BUILD_ROOT_DIR\common_config\MyConfiguration.vgdbsettings

    If I place a valid *.vgdbsettings in that location, and specify it in the project (at *.vcxproj level), e.g.:

    <NMakeOutput>$(BUILD_ROOT_DIR)\common_config\$(Configuration).vgdbsettings</NMakeOutput>

    I get the following output:

    Build/launch failed: Could not find a part of the path ‘F:\mycode\libraries\somelib\projects\win\$(BUILD_ROOT_DIR)\common_config\MyConfiguration.vgdbsettings’.

    So it looks like the VGDB engine may be interpreting NMakeOutput’s value as a relative path in all situations – ideally I’d want to be able to specify an absolute path.

    If instead, I specify a relative path to my common configuration folder, e.g..

    <NMakeOutput>..\..\..\..\..\common_config\$(Configuration).vgdbsettings</NMakeOutput>

    I get the following output:

    1>  VisualGDB: Run “C:\cygwin\bin\make.exe CONFIG=CrossCompileMac” in directory “F:\mycode\common_config” on local computer
    1>  make: *** No targets specified and no makefile found.  Stop.

    .. as if “make” is now treating the parent folder of the *.vgdbsettings as its working directory.

     

    Recap

    What I’d like to do is:

    1. Specify the *.vgdbsettings file in a common *.vsprops (so that the specification is inherited by multiple *.vcxproj files)
    2. Have that one single *.vgdbsettings shared between multiple *.vcxproj in different folders

    Is that supposed to be possible?

     

     

    #7892
    support
    Keymaster

    Hi,

    The problem happens because VisualGDB needs to parse the .vcxproj file when building the project and it does not have the VS API available at that point, so it does not check included property sheets. Hence each project needs to specify the path to the settings file explicitly. Also due to the performance limitations of VS, the settings file name needs to be named exactly as <Project>-<Configuration>.vgdbsettings file, as otherwise some of the context menu GUI won’t be able to find it.

    The easiest workaround would be to symlink the files via the mklink commands. We could also add a feature to allow linking property files, e.g. each of your project’s .vgdbsettings files could contain something like <LinkedFilePath>$(BUILD_ROOT_DIR)\…</LinkedFilePath>  and then VisualGDB would load the linked file instead of the per-project files. Would that work for you?

    #7894
    angus_fx
    Participant

    Thanks for the explanation.

    Your suggestion certainly helps somewhat – however..

    With what you’ve proposed, we’d still have to add each new configuration to each project explicitly. With the number of platforms we target, that’s an overhead I’d prefer to avoid if possible: MacOS & Linux; x86, x64, ARMv7 & ARMv8; debug and release builds.. 16 possible configurations, not counting niche setups to target particular development boards etc.. And that’s in addition to our MSVC++/Windows platform targets. (You can understand that I probably don’t want 16 sets of vgdbsettings per *.vcxproj).

    I understand you can’t parse the whole *.props inheritance tree, but performing basic substitution on $(Configuration) would at least allow something like this in my .vcxproj projects:

    <PropertyGroup > // < == note: no condition, I’m applying this for all configurations

    <NMakeOutput>../../../../global_build/config/$(Configuration).vgdbsettings</NMakeOutput>  // < == note: not passing the project name, yes I know this can cause context-menu problems but I’m not worried :o)
    </PropertyGroup>

    Or…

    <PropertyGroup > // < == note: no condition, I’m applying this for all configurations

    <NMakeOutputDir>c:\global_build\config</NMakeOutputDir> // < == could be an absolute path or relative to the .vcxproj,
    <NMakeOutput>$(Configuration).vgdbsettings</NMakeOutput>
    </PropertyGroup>

    This would allow the centralised management of the *.vgdbsettings which I’m looking for, without you having to worry about parsing *.props inheritance trees. Does that make sense?

     

    #7896
    support
    Keymaster

    Hi,

    Sure, we could easily add something like this. Could you send us a sample project file with your rule layout so that we could test it?

    BTW, if you are using your own build system and don’t need VisualGDB to update Makefiles, you can simply replace the build command with <VisualGDB.exe> /build <file.vgdbsettings>. This will eliminate the need to parse the .vcxproj files.

    #7903
    angus_fx
    Participant

    Thanks for your help – your suggestions re symlinks and replacing build commands prompted me to do a little more digging, and I’ve come up with an acceptable solution, using NMake to invoke a Powershell wrapper around VisualGDB.

    Here it is, for future reference:

    1. In the global *.props (Visual Studio Properties), get NMake’s Build, Clean etc. commands to invoke a wrapper. I pass it the Build Root directory, the name of the settings file VGDB will look for, and the current configuration (so that the script knows which base configuration file to copy).

    <NMakeBuildCommandLine>”powershell.exe” -file $(MyBuildRoot)\cfg\VisualGDBWrapper.ps1 “$(MyBuildRoot)” “$(ProjectDir)$(ProjectName)-$(Configuration).vgdbsettings” “$(Configuration)” “$(VISUALGDB_DIR)\VisualGDB.exe” /build “$(ProjectPath)” “/solution:$(SolutionPath)” “/config:$(Configuration)” “/platform:$(Platform)”</NMakeBuildCommandLine>

    (All the downstream projects therefore inherit that NMake command line)

    2. The powershell script:

    $MyBuildRoot = $args[0]
    $DestConfiguration = $args[1]
    $MyConfigurationName = $args[2]
    $VGDBCommand = """ + $args[3] + """ 
    $VGDBArgumentList = $args[4] + " " + $args[5] + " " + $args[6] + " " + $args[7] + " " + $args[8]
    $BaseConfiguration = "$MyBuildRoot\cfg\$MyConfigurationName.vgdbsettings"
    
    # Symbolic links would be better, but mklink permissions bugs on Windows 8 mean it's not available 
    Write-Host "copying $BaseConfiguration to $DestConfiguration"
    Invoke-Expression "& cmd /c del $DestConfiguration"
    Invoke-Expression "& cmd /c copy $BaseConfiguration $DestConfiguration"
    
    # Now invoke VisualGDB 
    Write-Host "Configuration $MyConfigurationName executing $VGDBCommand $ArgumentList"
    Invoke-Expression "& $VGDBCommand $argumentList"
    
    
    
    
    
    
    #7921
    support
    Keymaster

    Cool. Thanks for sharing this.

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.