You can start with creating a new project and incrementally adding existing source files to it.Once you decide on the build subsystem, there are several ways of importing the project structure into VisualGDB: Advanced CMake combines the advantages of both MSBuild and CMake, but requires CMake for building.Also Make-based projects can be built without Visual Studio, or VisualGDB. GNU Make can be useful if you are familiar with the Makefile structure and would like to customize it (e.g.MSBuild offers the best integration with Visual Studio and is very similar to the regular VC++ projects.You will also need to decide on the build subsystem to use: preprocessor macros, include directories, special optimization flags, etc.). Specifically, VisualGDB will need to know the exact list of files participating in the build, and all the build settings (e.g. You would be able to edit various build settings via Solution Explorer.Adding/removing files to Solution Explorer will affect the build.IntelliSense will always be synchronized with the actual build settings.This has several advantages over external build: It will edit the same directory list as the regular VC++ Project Properties page shown above: Managed BuildĪ better long-term alternative to externally built projects would be letting VisualGDB manage the build. You can use the regular VS Project Properties to specify the list of include directories and preprocessor macros to use for IntelliSense: For convenience, VisualGDB provides its own IntelliSense page for managing IntelliSense directories. IntelliSenseĮxternally built projects are internally implemented as NMake VC++ projects. They don’t have to match the Solution Explorer contents and will be accurate even if you keep Solution Explorer out-of-sync.
#KEIL 5 MAKE ELF CODE#
The list of source files used to set breakpoints and step through the code is taken from the debug symbols (special data inside the ELF file) that are produced during build. Note that the actual tools used to build the project can come from a different toolchain, or not be GCC-based at all. When you debug an externally built project, VisualGDB will use the gdb debugger from the toolchain you specified to debug the main binary configured via VisualGDB Project Properties. Initially, VisualGDB will populate it with the source files from the project directory, but adding/removing them will not affect the actual build. As long as the build command line produces a debuggable ELF file, VisualGDB will be able to build and debug it.Īs a side effect, the contents of Solution Explorer (that drives IntelliSense) will be completely independent from the actual build process. It could be using an exotic compiler, domain-specific build tools or BSP, etc. You can later change the build/clean command lines and the output path via VisualGDB Project Properties: This type of import will work with any project type regardless of the underlying tools. If you are importing an embedded project, VisualGDB will also ask for the toolchain and device type, however it will only be used to automatically configure debug tools and IntelliSense, and hence can be set very loosely. In order to import an externally built project, simply select “ Specify a build command line manually” in the Embedded (or Linux) project wizard: VisualGDB will ask for the build/clean command lines, as well as the path of the build output, and will create a basic project. mbed-cli) to build the project, while fully mapping the low-level build settings to convenient Solution Explorer GUI. VisualGDB will use the external tools (e.g. CMake, Arduino, ESP-IDF, Mbed, NRFConnect), you can enjoy the benefits of both approaches. Normally, we advise starting with the External Build to quickly get building and debugging to work, and then switching to Managed Build for projects that will be actively edited.Īdditionally, if your projects are compatible with one of VisualGDB’s Advanced Project Subsystems (e.g. IntelliSense would also work after you configure it manually. Although you won’t be able to edit the project settings via VisualGDB GUI, the building and debugging will work. External Build where VisualGDB will launch the explicitly specified command line to build the process and will use the explicitly specified output file for debugging.It requires more initial setup, but provides deeper GUI and IntelliSense integration. Managed Build where VisualGDB will directly manage the build process.VisualGDB supports 2 different ways of importing most external projects: This page outlines these mechanisms and explains the differences between different ways of importing projects. VisualGDB provides several mechanisms for importing external projects so that you could build and debug with Visual Studio.