[joeb]

I’m presuming that as long as anything that I bring along to build is backed up, e.g. older Visual Studio and older external code generators (ST32 CubeMX), that the version of VisualGDB that I use would always fetch the latest version of any packages from your servers that are known to work with it. Then everything works as expected if I come back to an old project.

OR. Are you saying that VisualGDB will always fetch the latest copy of packages that are on your server, and that some of these packages may not work properly with the VisualGDB that fetched them?

Sorry if that is a dumb question, but the reason I’m looking into VisualGDB is it saves me from all the hassle of setting up all these various open source things that think it’s fun to have to write a ton of scripts and pull in various dependencies yourself before something will work. So far, VisualGDB seems excellent at that, and I worry that I will need to know all the raw config stuff in the future, anyway, if I don’t continuously upgrade VisualGDB to keep up with the latest packages that it might pull in.

 

 

[joeb]

My trial has expired and I’m figuring out if I should purchase ‘Custom’ at this time, so I can’t try the diagnostics procedure yet.

What parsec67 pointed out holds true with my memory of the situation.

I remember now that when I would regenerate STM32 CubeMX (ST Micro auto-generated boilerplate config) files, that Visual Studio would warn about line endings, which I would always accept to correct the line endings. This should mean that Clang never saw the incorrect line endings though. It just saw a new file with several modifications change all of a sudden.

Also, yes, the context highlighting gets messed up, even with simple

#if 0

blah blah

#endif

blocks around temporarily unwanted code portions.

 

[Author]

Posts