The answer is probably as always it depends... ;)
Your decision path looks like this:
- If you target dual-core then there is at this point (CubeIDE <=1.4.2) no support for static libraries for dual-core, TrustZone or MPU devices. Only single core STM32 devices... So for these more complex devices you have to hack your way...
- Consider if the library will target only one Cortex-M core or be shared between let's say M0 and M3... Because this will have implications of your setup.
- If library is only targeting ONE core
- you can use the STM32 project wizard
- Select C or C++
- Targeted Binary Type = Static library
- Project type STM32Cube or Empty. With STM32Cube you dont get any ioc-file for this --> No MX support. So Empty may be just as good and more clean...
- Once project is created, you may want to setup different build configs for slightly different library builds... But be aware there is a bug in Eclipse/CDT leading to project references not working properly --> triggers unnecesary builds.
- once project is created, read the User Manual on how to include a library into your application project(s)
- https://www.st.com/resource/en/user_manual/dm00629856-description-of-the-integrated-development-environment-for-stm32-products-stmicroelectronics.pdf, see chapter 2.5.0 - Include libraries. Assumes UM2609 rev1...
- If library is targeting multiple different Cortex-M cores. Truely shared code. Then the problem is that CubeIDE only supports one Core per project. So you need to separate your own code into Core specific code and code shared between different cores.
- Create a static library like in bullet 2.1.1. But make one such project for each core you want to build the library for.
- Create a File > New > Project > General > Project. This project will just serve as a container for shared code. The project itself is not even C/C++ project. Just pure container.
- In this project add folders for code File > New > Folder … <-- place your share code here.
- In each library project link in the code folder from the container project.
- In the library project right-click on the linked folder and go to resource configuration to make sure files are NOT excluded from build.
- The include paths of the library projects must probably point to the shared code folder in the container project.
If you only target one Cortex-M core it is quite simple. If multiple cores. Then there is no official good support. So the above is just an experimental approach that probably could work...
I imagine the Use Case with "shared code targeting multiple cores" to be common, nevertheless we do not get so many requests about this...