STM32CubeIDE cloning (copying) a project

[chriskuku]

A usual approach is to branch from a given project by making a copy of it and develop further on the copy, leaving the original intact.

How can this be achieved in the STM32CubeIDE project tree?

I tried it by copying the directory in the filsystem, to a different directory, edited every file containing the original project name to the new one. Even edited the .metadata and every occurence of the original name in the new directory tree. It lead to an existing new entry in the tree view Could be that I even did an Import by browsing to that new directory.

But the result was that I was said it not being a CDT project when I wanted to open the properties on the new project icon.

What is a safe way to do achieve this?

[chriskuku · Accepted solution]

---

@Piranha wrote:

---

CubeIDE, as every Eclipse based tool ... allows every developers to works as he prefer

---

That is exactly the thing the Eclipse's workspace and overall design doesn't allow. Read this post for details. If

 I must say that - from my own experience - the "copy/paste in the project tree"-method worked for me and is *the* solution. I have no links in my projects. Maybe there are problems when one is using links.

[PR.10]

I do agree that eclipse workspace is a terrible idea. It is probably the main reason why it never became main stream popular. The project should be relative to a project file path like in EVERY other IDE.

HAL code generator is portability compromise you can not expect to cover every use case by a gui form. For polish product I write optimized code using LL based on datasheet but it great to have an HAL prototype option for validation tests.

The only relevant alternative to eclipse is VS code and that is worse in every other way imaginable except the project file. Nothing is perfect and in my case Eclipse is still better for the actual development work.

I would prefer if it was integrated in Visual studio IDE / community version. But that would be limited to windows so I understand why Eclipse was chosen.

[Harvey White]

There is an alternate method.  My entire project is in a directory with sub-directories.  The configuration files, except for a file identifying the board, are contained there.

I went through a period where the only way I could get the IDE/compiler to find anything was to include the absolute path.  Needless to say, changing to another computer was painful. 

What I did find is that adding the entire subdirectory by using source location under properties worked, with limitations.

the directory my project is in is called SUBSYSTEMS

Therefore, pointing the source location to SUBSYSTEMS worked. 

This required the following for any include file

#include "SYSTEM_CPP\SYSTEM_DISPLAY.hpp"
#include "COMMON_CPP\CPP_LINK.hpp"
#include "GRAPHICS_CPP\string.hpp"

Where the directory structure was SUBSYSTEMS for the project, and SYSTEM_CPP, COMMON_CPP, and GRAPHICS_CPP for subdirectories. 

This seems to work well.

This did not seem to be explained in the documentation.

The idea is that every project has a configuration file which uses #ifdef to enable and disable subsystems, and all projects have common code under SUBSYSTEMS.  Naturally, main.c and main.h along with the standard C support files are configured by CubeMXIDE.

[PR.10]

I used to work with / in include paths in some arduino project in VS code and it quickly escalated to madness due to various build system quirks, so I try to avoid it at any cost :)

I use folder with actual source code outside of the Eclipse project folder. And the project folder is outside of workspace. So there is no hierarchy.

There is and option to use path variables like this

${ProjDirPath}/../code_files/Framework

This works for folder and files even link folder. It also works for include path so projects does not  break when i move the root folder of the entire thing.

The format of eclipse project file is a mess so the only sane way is use gui to do that change. Once you find the macro name and where to put \ or / Adding a folder is a rare 1 time action, so I am fine with that.

Unfortunately nothing like that works for eclipse workspace but that is generally a source of endless pain anyway. At least it seems to update correctly when the project is opened from the new location.

It the moment I do not share the code with a linux machine but since it does accept / I assume it would work there too.

[Harvey White]

I'm stuck with CubeMXIDE, which means eclipse. 

The method I use works with new projects, which happens frequently at times.  The overall structure is \documents\projects\arm_projects\project 42\

under that is SUBSYSTEMS (custom code), side by side with that is projects\<individual project name> which has the CubeMXIDE structure in it, with the IOC file, .src, .inc, etc.

creating an individual new project (with a borrowed IOC file or not) results in another subdirectory <individual new project name> under projects.  Pointing the CubeMXIDE project "source files" at the SUBSYSTEMS directory seems to work, and is easier than trying to add paths (which for some reason includes set up in the project don't really work for me).

This works, and should be well behaved even if I move the entire projects (top level) to another drive.

Long as it works, I'm fine with it.