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?

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"