Forum Replies Created
I have managed to share a variable between VisualGDB and the MSBuild system by using an MSBuild Property sheet which is visible in all configurations and importing this sheet to VisualGDB settings.
Please find attached screen shots of settings, I have not configured any special mechanism; set User Variable with a default value, then use it in the MSBuild settings page.
Attachments:You must be logged in to view attached files.
Actually going back to my original question, I created a “User Variable” in the VisualGDB settings. The default value is propogated to the build system OK but not updated in the “Before building” action. If the VisualGDB value is updated why is that not then set in the “VERSION_STRING” in my example?
Thanks, I have created a new property sheet which can be seen by multiple projects/configurations, that bit is working. I don’t understand how to ‘invoke a tool to generate it’ though. Please can you explain further?
Creating a header file with the version information is of course very easy but how can I use the definitions in the header file in VisualGDB?
It was only after I renewed my subscription last year and updated VGDB that almost all my projects stopped working.
Well I’m pleased to say I managed to get this working myself eventually, just as well since it appears I’m on my own. If it helps anybody I think what fixed it was pressing “Rebuild MSBuild & Intellisense files for this toolchain” on the MSBuild settings tab.
I am able to continue working now – I have downloaded the updated version from the link above (now 126.96.36.19987) and re-installed. It is working again but I don’t know if it’s the updated version or the act of re-installing that’s fixed it.
I had previously tried closing and re-opening VS and I did go through the procedure of changing a setting on the VGDB properties page, to no avail.
A new error preventing me from even building now:
<span>Severity Code Description Project File Line Suppression State
Error MSB4062 The “InitializeFastUpToDateCheckFile” task could not be loaded from the assembly C:\Program Files (x86)\Sysprogs\VisualGDB\\Sysprogs.Build.Tasks.dll. Could not load file or assembly ‘VisualGDBCore, Version=188.8.131.52, Culture=neutral, PublicKeyToken=8f764369eb712693’ or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. LocatorBTLE C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\FastUpToDateCheck.targets 5
This has now brought me to a halt again.
Thanks for proposing some fix for this. It would be quite acceptable if all I have to do is select a checkbox and the settings I make in VGDB are then applied as previously. Or, would it make sense for the functionality of such a feature be to set the compiler command line options as per the CFLAGS in the VGDB page and ignore any settings in VS?
This has now become unacceptable. Every previously created project I open (all are standalone) now fails to build. I updated my subscription and Visual GDB in order to make use of the new features for ESP IDF projects (which I ended up not using) and that has broken everything else I have worked on in the past two years. I’ll bet there’s loads of others out there with the same problem but they just haven’t realised yet.
The only solution I can see is to roll back Visual GDB and accept that I won’t ever be able to use newer versions of GDB or go through every project I have changing the settings, compiling, checking checksums, creating new version control entries…
I’m not sure there’s a good answer to this. The ability to assign different values to the same setting in two different places is really bad.
What concerns me is not knowing which compiler or linker settings that I make in the VGDB properties page will be used and which will be overridden. I don’t think it’s feasible to remember or even have a checklist of which ones are duplicated.
Perhaps the best solution would be for VGDB to warn if any settings are detected in the VGDB properties page that may be set elsewhere or indeed have different values set elsewhere.
Further testing – going to the “standard” properties page, optimisation was set to O0. Changed that to O2 and it changes. So it seems that setting now overrides the setting in VGDB properties page.
Just based on very quick test.
BTW – all projects are standalone. I create the projects using the wizard and specify flags manually.
PS I have also seen some issues where files organised by filters seem to move out from the filters back to the root. That seems to happen when I add files to the project folder. That’s another story for later though.
I am just getting back to a different project and it occurred to me that the past 2 days I have spent on that project trying to get to the bottom of an issue may be due to the -O2 flag! I actually only got the code working by going to GNU build system. I knew the code had to be built with -O2 flag but had checked numerous times that it was set so I was investigating all sorts of other possibilities. With the GNU build on that project I was able to switch -O2 on and off to demonstrate to my satisfaction the code worked/didn’t work according to the flag.
I am going to copy that project to my backup PC to see if it will work with MSBuild on VGDB 5.3R8.
Well, actually I just checked on that project with –verbose and it is being compiled with -O0 instead of O2. That will be the cause of my problems there as well.
- This reply was modified 4 years, 8 months ago by ChangedDaily.
Hi, I have rolled back to V5.3R8 on my backup PC and that is working as expected. Answers to easy questions:
Actual output with 5.4R3:
COLLECT_GCC_OPTIONS=’-mthumb’ ‘-I’ ‘STLib/inc’ ‘-ggdb’ ‘-O0’ ‘-D’ ‘RELEASEVERSION=5503’ ‘-D’ ‘TESTDEFS_DEBUG_UDP_CONTENTS’ ‘-D’
‘CONFIGNAME=”Code_GSM”‘ ‘-D’ ‘USE_DEV_SERVER’ ‘-D’ ‘RELEASEVERSION=5503’ ‘-D’ ‘DEBUG=1’ ‘-ffunction-sections’ ‘-fdata-sections’
‘-Wpedantic’ ‘-pedantic-errors’ ‘-Wextra’ ‘-Wconversion’ ‘-c’ ‘-march=armv7-m’ ‘-v’ ‘-c’ ‘-o’
CFLAGS are set as follows: -O2 -pedantic -pedantic-errors -w -Wextra -Wconversion -c -xc -mthumb -march=armv7-m -ffunction-sections
I’m not attaching screenshot as my previous attempts at that have failed.
C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\bin\arm-none-eabi-gcc.exe -ISTLib/inc -ggdb -w -Werror -O2
-DRELEASEVERSION=5503 ‘-DCONFIGNAME=”Code_GSM”‘ -DUSE_DEV_SERVER -DDEBUG=1 -ffunction-sections -fdata-sections -pedantic
-pedantic-errors -Wextra -Wconversion -c -xc -mthumb -march=armv7-m
Note the main issues here are that O2 has changed to O0 and the -w doesn’t appear at all with 5.4R3.
I’ll get further info later.
- This reply was modified 4 years, 8 months ago by ChangedDaily.
Thanks for help. Opening the HELP window didn’t work for me but following on from your thoughts about the cause I closed the solution (not VS) and reopened it and the properties page is back. I’ll probably play around with other combinations to find the easiest. At least I know I can (hopefully) always get the option back.