Command line rebuild ignores -Wall

[bbr]

Hi,

I have noticed a strange behaviour when building with -Wall with VisualGDB.exe outside of Visual Studio.

The attached sample does (correctly) show build errors when the release configuration is build inside Visual Studio (Rebuild). But when building the same project on the command line with 'C:\Program Files (x86)\Sysprogs\VisualGDB\VisualGDB.exe' /rebuild .\VisualGDBRebuildBug.vgdbcmake /platform:VisualGDB /config:Release the build succeeds without any errors.

I have also noticed that the behaviour for the /build switch depends on the build state. When building with /build on the command line with a clean build state no build errors are shown. However when a build inside Visual Studio was started before building on the command line with /build, the command line build will also show the build errors.

It looks like

Best regards,

Bernhard

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This is by design. Unless you do a full rebuild, the build system only builds the files that are out-of-date (i.e. the sources have changed more recently than the objects). Files that are up-to-date are not rebuilt and the warnings that were shown during their compilation will not be shown again unless these files become out-of-date again. This is standard behavior for all build systems we are aware of and is not specific to VisualGDB.

[bbr]

Hi,

of course this explains my second observation that when a build with /rebuild once succeeded on the command line it will succeed again with only /build.

But this does not explain why the command line build with /rebuild does not have a build error at all.

[support]

Hi,

If you believe VisualGDB is working incorrectly, please provide complete unambiguous steps to reproduce the problem from scratch. The steps should start with creating a new project, and should either mention every involved setting, or include screenshots of every involved wizard/settings page and every other change. They should also include any relevant logs.

Please see our problem reporting guidelines for more details.

[bbr]

Hi,

in my first post I have attached a sample project based on a basic example containing code which should have a build error when compiled with -O3 and -Wall with GCC.

To reproduce the problem following steps should be used:

1. Download and extract the ZIP file
2. Open the solution inside Visual Studio
3. Select Release as Configuration
4. Rebuild the solution
5. Note that the build fails due to build errors. This is correct and expected behaviour.
6. Switch to a command line and navigate inside the extracted directory.
7. Build the project from command line with "C:\Program Files (x86)\Sysprogs\VisualGDB\VisualGDB.exe" /rebuild .\VisualGDBRebuildBug\VisualGDBRebuildBug.vgdbcmake /platform:VisualGDB /config:Release
8. Note that the build succeeds which is neither expected nor correct.

 

[support]

Thanks, this is a different issue. When using the VisualGDB.exe /build or /rebuild command for Advanced CMake projects, it was not properly passing the build type to CMake, so it ended up building the debug configuration (despite using the release folder).

We have fixed it in this build: VisualGDB-5.6.3.4195.msi

We also recommend building Advanced CMake projects by dumping the build/configuration command lines to batch files as shown here.

[bbr]

Thanks, the new build works as expected.

As the command line build is mainly used for continuous integration I doubt that the batch file is a suitable solution. Wouldn’t it require to manually regenerate the batch file when certain project changes are made? Also is there an option to force a rebuild with the batch file?

• This reply was modified 3 years, 4 months ago by bbr.

[support]

There is no need to regenerate the batch files unless you change global parameters, such as the toolchain or the environment. The batch files simply invoke CMake to parse the CMakeLists.txt files, generate the actual build rules, and then build the project with them. This workflow will automatically pick up any changes in CMakeLists.txt and the source files.

Here’s the contents of a typical batch file for CMake:

cd /d C:\projects\temp\DemoProject\build\VisualGDB\Debug
set LANG=en_US.UTF-8
set PATH=c:\SysGCC\arm-eabi\bin;%PATH%
set TOOLCHAIN_ROOT=c:/SysGCC/arm-eabi
set EFP_BASE=C:/Users/virtual.SYSPROGS/AppData/Local/VisualGDB/EmbeddedEFPs
set TESTFW_BASE=C:/Users/virtual.SYSPROGS/AppData/Local/VisualGDB/TestFrameworks
set TESTFW_BASE_LOCAL=C:/Users/virtual.SYSPROGS/AppData/Local/VisualGDB/TestFrameworks
"C:\Users\virtual.SYSPROGS\AppData\Local\VisualGDB\CMake\bin\cmake.exe" ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DTOOLCHAIN_ROOT=c:/SysGCC/arm-eabi -DCMAKE_MAKE_PROGRAM="C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe" -DCMAKE_TOOLCHAIN_FILE=<...>/toolchain.cmake -DPLATFORM=VisualGDB -DLOCALAPPDATA=C:/Users/virtual.SYSPROGS/AppData/Local

It references various common paths and the toolchain.cmake file, but doesn’t contain anything that would change when you add a new source file or a target.

[Author]

Posts