- This topic has 9 replies, 2 voices, and was last updated 5 years ago by
.
-
Posts
-
Current arm GCC toolchain release is based on GCC8.3, and, if the pattern continues, early next year will be GCC9 (which will likely resolve several issues that required notable workarounds in my firmware projects). Is there any intention to update/add UI for msbuild compiler flags for these newer versions? Language standards (C17/18, C2x, c++17, c++2a) mostly (can be specified on command line, but still leaves parse errors in the editor and confuse people because it’s specified in an unusual location).
On the topic of msbuild projects
- a nice feature would be a makefile converter (msbuild -> make). The lack of this option has proven to be a major downside of the msbuild projects
- Warning flags (in particular) beyond the default quickly fill up the “advanced/additional options (C++ files)” field and the UI doesn’t handle this as well as other fields that have lengthy values. I have ~20 different options in that field as the project also includes C files (that generate warnings when they receive unknown options). It’s also a little odd that the command line and C/C++ specific options are so seperate
- It seems to be nigh on impossible to create an embedded project static library without a BSP link. This makes splitting into multiple projects less than ideal. My preferred solution to this would be to push the BSP into it’s own static lib project by default. This would significantly reduce build times when multiple projects in a solution use the same BSP (I have to do this by hand currently and it is fragile to changes in the projects referencing the BSP lib), and make static libs much easier to create and use
Hi,
No problem. We have updated the C/C++ standard list in the following build: VisualGDB-5.5.2.3363.msi
Regarding the other suggestions:
- We generally don’t recommend using GNU Make as it does not automatically handle long command lines (i.e. doesn’t provide an easy way to generate response files without running into the same command line length limitation). Our MSBuild back-end is designed to handle this automatically, and is also highly optimized compared to GNU Make. If you could let us know why you are trying to convert an MSBuild project to GNU Make, we should be able to suggest a better solution.
- We have added support for most commonly used GCC warnings to VisualGDB 5.5 (see C/C++->Warnings). Generally we want to avoid adding all of the warning options from the GCC documentation to avoid overloading the window and making it hard-to-navigate. However, if you could let us know the specific warning options you are commonly using (and other GCC options not covered yet), we will be happy to update the VisualGDB GUI to include them. You can also try tweaking the <VisualGDB Dir>\Rules\PropertyEngine\Common\cflags.prop file to your liking. It will immediately affect CMake projects and you can send us your changes if you would like us to propagate them to MSBuild projects.
- Regarding the static libraries, we are currently designing an experimental CMake-based embedded project type that will greatly simplify the use of static libraries, targeting multiple devices from the same project, etc. We will include it in one of the next preview builds of v5.5 over the next few months.
- Interacting with Linux devs who occasionally want to build/debug with their own tools. I still want the msbuild to be the master project, but make files can be used with any environment and as the current standard, they come up a lot. My current solution for building (barely workable) is a script which scrapes the .rsp files into a zip, and a second one which turns those into a series of build commands but it doesn’t help with tooling
- I didn’t expect *all* of GCC options/warnings to be added, but the editing experience for the “additional options…” fields is sub-par compared to say the preprocessor definitions edit window (each option on a new line). For reference, this is my current set of default options for the C++ field:
- -Wno-register -Wno-missing-braces -Wno-psabi -Wformat=2 -Werror=reorder -Werror=format -Werror=format-extra-args -Wshadow -Wnon-virtual-dtor -Wcast-align -Woverloaded-virtual -Wfloat-conversion -Wmisleading-indentation -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wnull-dereference -Wdouble-promotion -Wconversion -Wstack-usage=256 -Wstrict-aliasing
- -fconserve-stack may be a flag worth adding to the optimisation UI.
- Excited to hear more about this. CMake resolves my main issue with seperated projects in msbuild (public/private include directories, preprocessor defines, …)
Thanks for sharing your list of commonly used warnings. We have reviewed them and added most of them them (except for the -Wno-psabi that appears too specific) to the VisualGDB GUI. Please try this build: VisualGDB-5.5.2.3372.msi
The C++-only warning options will be automatically dropped for Plain C files. Let us know if you have further feedback/suggestions.
Your current workaround with generating the scripts based on the .rsp files is reasonable. That’s what we usually suggest doing if you need to build an MSBuild-based project outside VisualGDB. The new CMake project subsystem will indeed eliminate the need for it.
cmake will indeed resolve my issues with msbuild, another reason to look forward to it.
I’m having some trouble with the 5.5 installer (5.4 also after testing :/). As soon as the installer hits “Status: Copying new files” it pops up the error “The specified account already exists”. Please advise what can be done to resolve this conflict
EDIT
Resolved by: https://support.microsoft.com/en-ca/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
OK, testing linked 5.5 build, the new options are good 🙂
Feedback on new build output window: I like the highlighting in the new “VisualGDB Build” window, it would be good if it could still be echoed to the normal visual studio output/error list windows. In a solution containing cross platform elements having just 1 window to look at (for e.g. solution rebuild) is strongly desired.
Hi,
No problem, this is already supported. Simply use the “configure” button in the new output window’s toolbar to open the Advanced Output Settings where you can switch between the regular output window, advanced output window, and fine-tune other output-related parameters.
Ok, that sort of works. Visual Studio needs a reboot after that setting is changed to completely apply the setting and not throw erroneous errors in the output (in msbuild/gcc.targets. Didn’t prevent the build succeeding)
- You must be logged in to reply to this topic.