Build without VisualGDB

Sysprogs forums Forums VisualGDB Build without VisualGDB

This topic contains 6 replies, has 2 voices, and was last updated by  Ocef 1 week, 1 day ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #23680



    I work for a small company and we are looking for alternative IDEs to use, including VisualGDB. We are testing the trial version and we really like it so far: developing, debugging, everything is nice. If we chose your IDE as our default environment, then we are going to purchase the full version for every developer, of course.
    But, we have an automated build server where we don’t want to debug, we don’t want to use any Visual Studio features, just build the software and that’s it. Is there any way to do that without getting an extra (and mostly unused) license?

    Thank you for your answer.




    Great to hear you found VisualGDB useful. There are indeed several ways to build VisualGDB projects on the build server without installing VisualGDB there.

    Once way would be to create a CMake-based or Makefile-based project. For these type of projects the build is managed by the external Makefile (or CMakeLists.txt file) and hence they can be built by running Make/CMake manually.

    If you would like to use MSBuild, please check the .rsp files generated in the build directory on your Windows machine. Each RSP file contains the exact command line used by VisualGDB to compile or link that file (VisualGDB would simply run <gcc executable> @<relative path to the RSP file> from the main source directory). You could then create a very basic script that will enumerate the rsp files and reconstruct the build script for the build server (you will need to replace the paths in the .rsp files via some basic pattern matching though).

    Let us know if you have further questions and we will be happy to help.



    Oh yeah, that was pretty straightforward. The makefile version works fine. Thank you.

    Here is the second question:

    What if the build server is on linux? The toolchain used by VisualGDB doesn’t work there. I managed to compile it with manually editing the makefile (I know, I should, but just for testing):

    CC := arm-none-eabi-gcc #$(TOOLCHAIN_<wbr />ROOT)/bin/arm-eabi-gcc.exe
    CXX := arm-none-eabi-g++ #$(TOOLCHAIN_<wbr />ROOT)/bin/arm-eabi-g++.exe
    LD := $(CXX)
    AR := arm-none-eabi-ar #$(TOOLCHAIN_<wbr />ROOT)/bin/arm-eabi-ar.exe
    OBJCOPY := arm-none-eabi-objcopy #$(<wbr />TOOLCHAIN_ROOT)/bin/arm-eabi-<wbr />objcopy.exe

    Is there any way to do it with the IDE? I mean: it detects the OS and changes these values automatically somehow.



    Good to know it works. Since building on Linux is a fairly rare use case (and would require slightly different configuration each time), VisualGDB doesn’t support it out-of-the-box, however it is designed to make it relatively straight-forward. We would advise modifying the Makefile to conditionally include a file called linux.mak that would override CC, CXX and other variables set by debug.mak or release.mak.

    Since VisualGDB only edits specific statements inside the Makefile and keeps the general structure, this will only need to be done once.



    I have created a new makefile (linux.mak) with an if statement that checks the OS and if isn’t windows, then it overwrites the variables.

    My last question: Inside debug.mak (and release.mak) is it a good place to include it:

    ADDITIONAL_MAKE_FILES := stm32.mak linux.mak


    It works, I am just worried if the IDE would overwrite it in the future.



    Good to know it works.

    The ADDITIONAL_MAKE_FILES line in debug.mak and release.mak might get overridden if you edit some of the settings. A safer bet would be to add linux.mak to this variable in the Makefile itself (just before the ADDITIONAL_MAKE_FILES variable gets read).



    Thank you for your help, everything works fine.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.