Modify and Debug an existing C++ open source application with its own build scripts that use bazel

[NPari.17]

Hello!

I need to modify and debug (with all the useful tools available in stm32cubeide) an existing open source application for stm32G474 that is built using bazel. I mean somehow "seamlessly" integrating the whole build process into stm32cubeide. The build is standalone and I can run it without issues by itself but I don't know how to make this same build work from within stm32cubeide. I tried just including the source in a project and build using the built-in stm32cubeide setup but, apart from adding all the include paths, I can't figure out why the compile fails due to all sorts of c++ version and library issues. Obviously, the bazel build does some fancy stuff that I don't think I should (and have the know-how to) mess around with. There must be some clashes between what the cube uses and what the bazel build uses. Note that the bazel build scripts copy all the sources/libraries (including those it obtains from external repositories) to a local directory. Essentially, what I am asking is how to tell stm32cubeide that I want it to use the existing bazel scripts for building yet retain all the nice editing and debug facilities.

[TDK]

You can define custom build commands in project properties -> C/C++ Build -> Builder Settings.

A debug configuration can be set up to use the generated ELF file from the custom build script.

[NPari.17]

Thanks for your suggestion!

I have tried that and I cannot get the tool to stop appending extra arguments to my bazel invocation such as -jN if the parallel threads is enabled under the Behavior tab or the make targets like "all" or "clean". I tried turning all those Behavior options off and deleting the target names but then nothing happens. There must be an underlying mechanism that expects make style build. Or maybe the project has to be generated using c/c++ project style instead of stm32 project? Then I wouldn't get all the useful cubeMX generated code? There are so many "hidden" layers in this tool I fear I would have to spend days and days figuring this out. Unless someone out there has been through this before...

[NPari.17]

Thanks for your suggestion!

I have tried that and I cannot get the tool to stop appending extra arguments to my bazel invocation such as -jN if the parallel threads is enabled under the Behavior tab or the make targets like "all" or "clean". I tried turning all those Behavior options off and deleting the target names but then nothing happens. There must be an underlying mechanism that expects make style build. Or maybe the project has to be generated using c/c++ project style instead of stm32 project? Then I wouldn't get all the useful cubeMX generated code? There are so many "hidden" layers in this tool I fear I would have to spend days and days figuring this out. Unless someone out there has been through this before...

[TDK]

It's a mess because every project does their build differently. So either you just live with the default, or spend the extra effort required to get it to behave exactly how you want.

The build steps are very flexible, but it will take some time. Spending days to set up a complex project in a new unfamiliar IDE sounds about par for the course.

Disabling parallel builds will get rid of -j12.

Choose your own option for build/clean in Behavior, or disable them. Delete "all" if you don't want that argument passed.

[NPari.17]

I'll keep trying for a bit. Thanks!