Generator for eclipse plugin for stm32 microcontrollers

I’m looking into creating a new generator.

I’m able too see the Name given to add_custom_target from target->GetName(), and
the target type is cmStateEnums::UTILITY. I am able to see the full path of generated file by calling target->GetSourceFiles() then cmSourceFile.ResolveFullPath(), i see one output file and one .rule.

However, I cannot figure out how to retrieve the COMMAND portion of add_custom_target given in the cmake file.

For what build system is your new generator?

1 Like

Its a generator similar to Eclipse CDT4.
This generator is for eclipse plugin for stm32 microcontrollers at
The .project and .cproject are the same type of XML, but generated specifically for this cross-compiler plugin for stm32.

I have it basically working, meaning the eclipse plugin is able to build the cmake generated project, but the post build steps are given in add_custom_target in cmake file. It should also work for stm32CubeIDE, since that imports these types of projects.

1 Like

CMake’s Eclipse CDT4 generation support is an “extra generator” that doesn’t actually provide the build system. The build system is still expressed as Makefiles and the CDT4 project files are just for viewing. The Makefiles have all the compiler, linker, and custom commands. It is not a good example for how to write a full generator.

Does the stm32 cross-compiler only work under the Eclipse plugin or can it work independently and you’re just trying to integrate with an IDE?

The generated .cproject might not work with recent versions of CDT. See


The path forward for Eclipse to provide an IDE experience for CMake projects is Eclipse Issue 545905 to add support for CMake’s file-api. The file-api has superseded the old “extra genrator” approach.

1 Like

I am only using eclipse CDT generator as an example. I did notice myself that it goes crazy with indexing subprojects.
I currently have my generator basically working using the extra generator approach, but i would move to file-api, if there is an example. .

The file-api is meant for external tooling to access CMake’s codemodel for IDEs. There are no file-api clients in CMake itself, except for the test suite. It is also not sufficient for actually building the project.

I’m still trying to understand what you’re trying to accomplish. Does the stm32 compiler work with the Ninja or Makefile generators or not?

the stm32 compiler works fine with unix makefile generator. Its actually called gcc-arm. It behaves just like gcc, it just cross compiles for arm.

The purpose of another generator is that some users want the IDE, because it provides the compiler, debugger, make, and all the tools.

Also, the microcontroller vendor makes a separate copy of IDE project files for every combination of hardware boards and software application, and cmake would generate the project for them, instead of manually creating IDE project files for infinite number of hardware + software combinations.

The purpose of another generator is that some users want the IDE

The purpose of the file-api is to offer IDEs a way to integrate with CMake build trees using any generator, including Makefiles and Ninja.

every combination of hardware boards and software application, and cmake would generate the project for them

CMake doesn’t support more than one target architecture in a single build tree.

ok, thats all good.

Just one thing i’ve noticed with file-api.
There are command fragments for target with target type is OBJECT_LIBRARY or EXECUTABLE.
But when type is UTILITY, no fragments are present in json reply.

cmake script can have add_custom_target() with COMMAND, then target type is utility for this target, and there should be fragments present from whatever command was given.

See CMake Issue 20463.