- This topic has 5 replies, 2 voices, and was last updated 2 weeks, 1 day ago by
.
-
Posts
-
VisualGDB 5.6
Visual Studio 2022I’ve been through the Create new Project wizard to create a Cygwin based project. This has been sucessful up to the point where I want to start changing “Makefile settings” in the Project Properties. In particular the “Make Command” setting and its sub-settings.
Two things seems to be going wrong
- the whole Makefile Settings view does not always reflect the actual settings stored in the .vgdbsettings file
- I can’t change the Working Directory field away from $(BuildDir), neither using a direct paste of a path nor using the browse button.
For example, if I paste in a path, click Apply, then Command changes to $(ToolchainMake), Arguments to $(ToolchainMakeArgs), and Working Directory to $(BuildDir), not matter what was in those fields before apply was pressed.
In the .vgdbfile I still see custom settings
<MakeCommandTemplate></div>
<SkipWhenRunningCommandList>false</SkipWhenRunningCommandList></div>
<Command>Make</Command></div>
<Arguments>-j -k FORCE_REBUILD=off</Arguments></div>
<WorkingDirectory>C:\Workspace\applications\NetOs App\D910</WorkingDirectory></div>
<BackgroundMode xsi:nil=”true” /></div>
</MakeCommandTemplate></div>When I build part of the output is showing that the cd still appears to be using $(BuildDir) irrespective of the settings in the .vgdbfile
1>Executable: C:\cygwin420\bin\bash.exe
1>Arguments: –login -c “cd /cygdrive/c/Workspace/applications/NetOS App VisualGDB && Make -j -k FORCE_REBUILD=off CONFIG=Debug”Hi,
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Hi,
You can always post on the forum, and if anyone else decides help, they are always welcome to do so. We just post a standard reply with the renewal link, so others would know why we are not investigating it further.
Either way, yes, the support and upgrades are always combined. You can generally use any VisualGDB version that was released before the support on your license expired. So renewing the license would always allow installing any version released before the renewed support period expires.
Hi,
Thanks for renewing your support.
This behavior is somewhat expected with the GNU Make projects. The regular Make project subsystem expects a particular Makefile layout, that places a few constraints on the project structure. One is that the build command should always run from the Makefile’s directory. The other one is that CFLAGS and other settings should be specified in a very rigid way, so VisualGDB can edit them using relatively simple regular expressions. You get the general idea by creating a new Make project, changing a few things via the GUI, and checking what files got changed as a result.
If you have an existing big project with non-trivial Makefiles, we would advise importing it as an externally built project. It will remove all constraints on the command line, but things like include directories would require manually updating the Makefiles.
A better (but more time-consuming option) would be upgrading to CMake. Unlike Make, CMake can produce machine-readable information about the project structure, so unless you do something really tricky (like custom macros), you can just select a target in Solution Explorer, change its properties, and VisualGDB will automatically find and edit the correct CMakeLists file defining that target.
- You must be logged in to reply to this topic.