I don't really understand why are you saying main.c is rarely modified, CubeMX will modify almost everything, adding all the initialization code, handlers, interrupts, headers... they're different for each controller!
Because I moved those to a template folder and in the pre-build code generation step a makefile is executed which has a target (currently a dummy file, read the relevant comment in the makefile) that copies this template main.c/h/stm32_xxx_it.c file, runs the codegen. So the files in the template folder are never modified by the codegen. If you change the templates it is automatically discovered by eclipse (no special config needed, since the template is within the main project), which triggers the pre-build code-gen step, make discovers that the prerequisites of the code-gen target is changed, copies the template to the target hw specific project/folder and runs the codegen on that.
And because eclipse can change based on the currently active configuration which include and source folder to use each hw target can have its own separate folder. This folder is where the pre-build step places the generated files.
What I don't want is a complex building system which is harder to fix/maintain than just few files Boards folder.
Its not at all complex, all of this is contained in a single makefile
https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/mcu/generate_sources.makefile, plus the project settings to run this makefile before the build.
And if the pre-build step don't even need to take into account the currently active target configuration, then the project settings becomes really simple: just trigger the pre-build step before build and build the hw config for all targets.
regular Eclipse+makefile+libopencm3
Eclipse does not work well (actually not at all) with normal makefiles. Its internal builder/indexer can't use them. If you go this way then eclipse basically becomes a fancy text editor and nothing more. And I would suggest cmake in this case, because with a simple makefile it's still difficult to depend on code generated by a previous step/target especially if you don't know beforehand what files are going to be generated (what drivers get copied, etc).
VisualStudio and IntelliJ IDEA can work with make/cmake based projects, but then you run into the issue of actually setting up the target platform SDK, as opposite to STM32CubeIDE where everything comes in one single package (compiler, support packages, IDE, ...).
So I would keep the STM32CubeIDE + its automatic makefile generation and solve this pre-build code generation step.