Sharing .c/.h pairs in Multiple Projects(Mainting .c/.h files whilst they are in development across multiple projects)

SSpen · ‎2020-02-23

Hi,

First post here. I've been using Eclipse previously with SystemWorkbench for STM32 and now the STM32CubeIDE.

I'm working on an embedded project which uses multiple microcontrollers and need to use the same .c and .h files for both (with different configs depending on which micro is being targeted).

I've been using symlinks in windows with the shared files located in a separate folder, however this isn't ideal due to having to setup new symlinks for new projects and iterations.

Ideally I'd like to have a separate folder with all of my different "libraries" (.c and .h) files which I can import into any project, and changes made in any project will update the files, and hance, their usage in other projects.

I've been trying to do this using paths and project preferences, but no luck so far.

Any thoughts?

Pavel A. · ‎2020-02-23

Linked resources. This is what you call "paths and project preferences"? Why no luck? They just work.

-- pa

SSpen · ‎2020-02-25

I would always get an issue where the header files weren't recognised

Ozone · ‎2020-02-25

I suppose you mean "not found".

You might need to add the include path manually to the build settings.

Another name for sources shared between multiple project would be "library".

Separate functionality, and implement it as a library project you can include in your sources.

In many cases, this means sources (not link libraries).

In my company, whe share library code across different architectures and toolchains.

mattias norlander · ‎2020-02-26

This is an interesting topic and we are surprised to not hear more complaints / feedback from users about this.

The problem you describe is equally valid in these use cases:

CompanyX starts protoryping project on NUCLEO board

CompanyX gets first custom PCB version

CompanyX gets PCB revisionY

CompanyX wants to develop several end-customer products based on the same platform code but using different STM32 MCUs

CubeMX does today not support creating "branched configurations", when you for example want to switch from MCUX to MCUY. Would be a very complex feature to implement and maintain.

So how to deal with the use cases described above or your original question? There is no "one solution". But here is an approach that can work and that scales quite well. Use "one container project" to store shared code. Link the folders of this project into your "product projects"

In your workspace do this

Create a new standard Eclipse container project for shared platform code. This can be just a standard general Eclipse project. It will not even be able to build by itself, but maybe fine?!
1. File > New > Project > General > Project > ... > Finish
2. Create a folder in this project which will serve as the folder you will link into all other "product projects"
In your "product" project (CubeMX based or not)
1. In project explorer select the folder created in step 1.2 grab it and drag it into your "product project". Hold down CTRL+SHIFT before dropping it to make sure that a link is created. The first option "Link to files and folders" is suitable.
2. Right-click on the just added folder in your "product project" > Resource Configurations > Exclude from build... > Deselect all.
  1. If this is not done, the folder will not be considered part of the build by Eclipse/CDT build system. Consequently code will not be built.
3. Include paths must be added in the "product project". The include path must still point to the folder structure in the "container project" (step 1)

With this approach you can share code. Of course for each "product project" some steps (2-3) need to be re-done. But there is always a cost to setup stuff :) The debugger will be able to resolve symbols so that source code look-up works.

Sometime you may need to right-click on a project and click "Refresh", when resources that you add are not visible to Eclipse. Could lead to compilation issues if the IDE cannot see a new file.

Feel free to try the approach and share your experience!

Just re-produce step 2 in all your "product projects" where you want to add the shared code.

You will need to version control the shared code project separately.

Piranha · ‎2020-02-29

Guys, do I understand it correctly - is all this mumbo-jumbo necessary because Eclipse cannot just add files from other (non-project) folders like... any other normal IDE?

Pavel A. · ‎2020-02-29

> is all this mumbo-jumbo necessary because Eclipse cannot just add files from other (non-project) folders like... any other normal IDE?

Of course Eclipse can add files from non-project folders. Eclipse is a normal IDE. But like with other power tools, you need to invest some time and learn it.

Mattias showed just one way to make a linked folder.

-- pa

mattias norlander · ‎2020-03-03

As Pavel said, this is just one way of supporting some common use cases in software development. There are probably several other ways to achieve the same thing, all with their respective pros and cons.

If you just want to add files into your project you can just drap+drop (hold-down CTRL+SHIFT to create link instead of physically moving/copying file) them into any source code folder. I stress source code folder and not folder since this is two separate creatures in Eclipse.

If a user were to move/copy a folder from one location on the file system into an Eclipse project root directory than this folder will not be part of the build. It will by default not be a source code folder. To make it part of the build, right-click on the folder in project explorer --> resource configuration --> exclude from build --> deselect all

It is also not a good idea to perform file operation in the background (OS file explorer or command-line) on files managed by Eclipse since Eclipse will be out-of-sync.

If a user were to move/copy a folder from one location on the file system into an Eclipse project source code folder, then naturally the added folder and contained code will be part of build.

Eclipse is quite flexible, but some default behavior is not really intuitive like excluding new folders/files from the project by default.