- This topic has 7 replies, 2 voices, and was last updated 2 years, 9 months ago by
.
-
Posts
-
Hi,
I want to use our build system to build nrfConnect projects but can’t quite see the simple way to do this.
With other VisualGDB projects I use MSBuild with a command line of the solution file, project name and configuration to build – but this produces the error:
warning MSB4078: The project file "xxxx.vgdbproj" is not supported by MSBuild and cannot be built.Is there a nice similar command line I can use to run the entire build process, using the environment variables and configuration from the project?
Regards,
Chris
Hi,
This happens because the build system does not have VisualGDB installed, so it cannot load the .vgdbproj files.
That said, NRFConnect projects are built directly by CMake with the NRFConnect build scripts. VisualGDB simply runs the build tools and interprets the results. Hence, you can build the project on your build server by manually running CMake and Ninja with the same command lines as used by VisualGDB (you may need to adjust some absolute paths).
Please refer to the following page for a detailed explanation how to CMake-based build projects outside VisualGDB: https://visualgdb.com/documentation/projects/cmake/#troubleshooting
This happens because the build system does not have VisualGDB installed, so it cannot load the .vgdbproj files.
Well, no. Right now I’m just trying to build on my day-to-day dev machine. There’s no point trying to get it working on CI until I can make it work locally. VisualGDB is most definitely installed. Its also definitely installed on the CI machine for that matter, as its already used for building ARM projects.
Yeah, I understood it was running CMake and ninja on build requests, but I was hoping this was easily accessible from running MSBuild or similar to trigger the process. Otherwise I need to remember to re-export the command line if I make any changes.
I’ve exported the build command as suggested and will run with that. It looks like the output build directory needs to be created manually prior which is ok. The .bat file does though contain some hard-coded paths specific to the local installation and source directory, so I’ll need to ‘finesse’ away the specifics to work from other machines. Again, this is why a MSBuild command line would be preferable.
Thanks,
Chris
Sorry for the confusion. The NRFConnect projects are not based on MSBuild. They use a completely different mechanism for loading and building, so the MSBuild executable will not recognize them. You can still build them by running devenv.exe /build if you prefer to use the same mechanism for all project types.
That said, if you have VisualGDB installed on that machine, it is easier to build the projects by running VisualGDB directly:
VisualGDB.exe /build <file.vgdbproj>
Ok, thanks – that’s a much better answer.
Doesn’t seem to be much documentation for command line VisualGDB other than providing no parameters and getting a help message.
But I’ve kinda got part of this working. But the steps I need to run are as follows (and this is for an nRFConnect / CMake based project).
- Clean the build – either by manually deleting the build folder or running visualgdb.exe /clean
- From within the IDE, right-click the project and Reload CMake Project (to generate correct cmake build files).
- Then I can use visualgdb.exe /build to build the project. I get an error at the end “error : Failed to merge NRFConnect binaries: The path is not of a legal form.” The .hex file is output correctly (which I’m after) but the merged.elf file is not produced.
Is there a way to do step 2 via the command line? For the record, the command line I’m using is this:
"c:\Program Files (x86)\Sysprogs\VisualGDB\VisualGDB.exe" /rebuild filename.vgdbproj /config:Debug /platform:It looks like it needs the IDE to run cmake correctly otherwise the error below occurs, and this also happens if I use the /rebuild switch instead. The noticeable difference in the output is the lack of the line “– Found toolchain: gnuarmemb (C:/SysGCC/arm-eabi)” that appears when it works, is not there when it fails.
Incidentally this matches what sometimes happens in the IDE if I remove the build folder then hit Rebuild.
CMake Error at C:/nrfConnect/v1.8.0/zephyr/cmake/generic_toolchain.cmake:36 (include):
include could not find requested file:C:/SysGCC/arm-eabi/cmake/toolchain/gnuarmemb/generic.cmake
Call Stack (most recent call first):
C:/nrfConnect/v1.8.0/zephyr/cmake/app/boilerplate.cmake:544 (include)
C:/nrfConnect/v1.8.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
-- Configuring incomplete, errors occurred!
C:/nrfConnect/v1.8.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:35 (include_boilerplate)
CMakeLists.txt:9 (find_package)CMake Error at C:/nrfConnect/v1.8.0/zephyr/cmake/dts.cmake:167 (message):
command failed with return code: The system cannot find the file specified
Call Stack (most recent call first):
C:/nrfConnect/v1.8.0/zephyr/cmake/app/boilerplate.cmake:545 (include)
C:/nrfConnect/v1.8.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
C:/nrfConnect/v1.8.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:35 (include_boilerplate)
CMakeLists.txt:9 (find_package)Hi,
The VisualGDB.exe /rebuild command should normally work just fine, as long as the platform and configuration are specified properly.
The issue you discovered was actually a rather obscure bug: VisualGDB was passing the TOOLCHAIN_ROOT variable to CMake (backward compatibility with other project types), that ended up overriding some internal Zephyr variables, and ultimately breaking the build. Loading the project from Visual Studio would use a slightly different logic that already contained a workaround for it, so the problem was limited to using the VisualGDB.exe /(re)build command line.
We have fixed the issue in the following build: VisualGDB-5.6.104.4542.msi
Awesome – you are correct that the problem is fixed in that version and I can build from the command line. Great stuff. Thank you.
One more question about the VisualGdb.exe command line. For use in CI I want to be able to pass the build number (from CI) into the build so that it can be reported at runtime. I do this in MSBuild command lines for other projects, but want to get it working here too.
I can pass this to the build from CMakeLists.txt (e.g. by the code below):, but I need to get it into an env var first. I could do a ‘set BuildNumber=x’ from DOS in the CI somehow, but this is ugly and dependent on a continuous shell. Is there a way to pass this into the build from the VisualGDB.exe command line, similar to the MSBuild ‘-p:BuildNumber=x’ option?
Example CMakeLists.txt:
...if(DEFINED ENV{BuildNumber})
target_compile_options(app PRIVATE -DBUILD_NUMBER=$ENV{BuildNumber})
else()
target_compile_options(app PRIVATE -DBUILD_NUMBER=0)
endif()Hi,
Good to know it works.
Passing variables from VisualGDB.exe command line to the build logic would be rather tricky due to the sheer number of different project types supported by VisualGDB, so there is no special option for this. That said, it’s extremely easy to work around: simply create a batch file that will first set the necessary environment, and then invoke VisualGDB.exe. As long as both commands reside in the same batch file, the environment will be carried over correctly.
- You must be logged in to reply to this topic.