Best way to duplicate a workspace with projects

[Anguel]

Hi,

Let's say I have a workspace with multiple projects (e.g. application project, bootloader project, etc.) for a product. Let's say this workspace is located in C:\ProductA. Now I would like to duplicate this workspace to use it for another product let's say ProductB, it will be located in C:\ProductB, but of course I want to also keep ProductA. After Googling a lot about doing this in Eclipse I now have found two ways to achieve this:

Option 1: Create a completely new workspace C:\ProductB from scratch and then import the projects from C:\ProductA into that workspace by ticking the "Copy projects into workspace" option. The problem with this approach is that all workspace settings will need to be imported in a separate step from the old workspace and I am not 100% sure that CubeIDE will actually copy all additional files and folders from the old folder.

Option 2: Do a filesystem copy of C:\ProductA to C:\ProductB and open C:\ProductB in STM32CubeIDE. The annoying problem here is, that all project links still point to the old C:\ProductA folder as Eclipse uses absolute paths! So a proposed quick solution is to simply remove the projects from that workspace (without deleting them from disk) and then reimport them (without having to copy them into the new workspace, as they are already there). After doing so all project links seem to point to C:\ProductB and all workspace settings seem to be still there.

Somehow I like the second approach better, as I do a manual full copy of all files contained in C:\ProductA to C:\ProductB, also if there are some additional files or folders they will be also copied over and I don't have to export/import workspace settings. What do the gurus think about this? Are there some possible drawbacks of the second approach I did possibly overlook?

Thanks in advance and best regards,

Anguel

[Cartu38 OpenDev · Accepted solution]

I fear no good solution (or at least no click button one) because already Eclipse is not so smart here (especially thinking linked resources). On top of STM32Cube is adding its own complexity definitively preventing to get any obvious solution.

Such said all is possible taking care.

Good is already you're not thinking to get a very different file location if your workspace. Moving from <path>/ProductA to <path>/ProductB is helping already. If you were thinking to revisit <path> depth would be I guess almost impossible (because linked resources).

From my point of view best is really a copy of original workspace (file system copy). Then looks for "ProductA" to "ProductB" replacement scanning all files within the new workspace. All files means all ... not only sources but tools metadata too. Thanks such forum exchanges we know already some .mxproject file if some is sensitive metadata.

Doing such sounds to me you may get some success.

PS: just in case do an archive (.zip or ...) of your orignal workspace. If failing within some metadat hacks we have seen thru such forum comments at a point some magic may despite working on your new workspace corrupt your original one (back to .mxproject stuff ...)

[Anguel]

Thanks @Cartu38 OpenDev​ ,

Now I cleaned and rebuilt the projects (both debug and release) then scanned for references to the original project's path.

Here is a list of the files still containing references to the old project folder:

 

In .mxproject the only references are under [PreviousGenFiles], I think this should not be a problem.

To make sure, I also renamed the old project folder and what is strange is that it was then recreated with the following file:

"...\OLD_PROJECT\STM32CubeIDE\.metadata\.ide.log"

with the following contents:

2021-06-02 12:54:38,902 [INFO] Activator:170 - 
 
2021-06-02 12:54:38,907 [INFO] Activator:171 - !SESSION log4j initialized
 
2021-06-02 12:54:40,454 [ERROR] LogOutputStream:74 - [STDERR_REDIRECT] Managed Build system manifest file error: Could not load icon "icons/chip.png".
 
2021-06-02 12:54:40,460 [ERROR] LogOutputStream:74 - [STDERR_REDIRECT] Managed Build system manifest file error: Could not load icon "icons/chip.png".
 
2021-06-02 12:54:40,470 [ERROR] LogOutputStream:74 - [STDERR_REDIRECT] Managed Build system manifest file error: Could not load icon "icons/chip.png".

[Anguel]

A short update:

Now I did a manual search and replace in config files only, no binary files, no log files, no .lnk files, etc.

If your old path has a slash in the directory path that has to be removed beware that the slash can be written as \, /, \\, //, \/, etc. in the config files - this is an additional problem.

For search and replace I found "InfoRapid Search & Replace" to be very useful.

These are the files in which I did a manual path replace: .mxproject, .log4j.xml, *.launch, dialog_settings.xml, *.prefs, *.json

This is so annoying and such a waste of time. I don't know how so many IDEs can be based on Eclipse and how this multi-platform IDE does not support relative paths.

[Cartu38 OpenDev]

Thanks for sharing full experience will help some of us relying on such community.

My 2 cents on some of your findings:

+ "load icon" issue have been reported on some other topics couple of time. I guess nothing related here to your on going workspace cloning activities. Hopes STM is looking at.

+ If .mxproject I would take care to [PreviousGenFiles]. Device configuration tool (aka. MX) is generating code for you but is also able to update it for you (incremental IP setup or ...). I'm pretty sure such "previous" is useful then to properly lead the update.

+ About relative path yes all such is a pain and would no blame Eclipse platform itself here. Eclipse is a framework (very valuable and proven one according to me). As a framework it's hosting various contributions ... all may not (by mistake) honor golden contribution practice ... leading to at a pain material ... pro and cons of open source and scalability

[Anguel]

Again, thanks @Cartu38 OpenDev​,

I think it was actually me who reported the strange icon problems in the past, looks like a cosmetic issue but I did not find a solution. Regarding the question why the new project put the log file into the OLD folder: It was probably because of .log4j.xml pointing to the old directory before I manually changed it. Many thanks for the heads up regarding searching the file for the old path.

Also thanks for the heads up regarding file generation, in any case I updated the .mxproject file to the new path.

Regarding the relative path issues: The sad thing is that these problems exist since Eclipse exists, IMHO there was plenty of time to address them, not sure what might be more important to developers than a stable environment that does not drive you crazy when you just want to change the directory your projects are in. I also had not expected that things built on top of Eclipse will propagate this problem even further, making straight-forward changes to projects actually impossible. Just googling how many people have problems duplicating their projects says it all. If ST wants to build its whole ecosystem around CubeIDE they should at least test and document the problems properly, not just point with the finger to Eclipse and leave it to the developers who should have indefinite time to solve existing and new issues every day and beta-test the new IDE versions. It was them who chose to use an Eclipse based IDE and even paid a lot of money. It is also amazing how few Eclipse related problems get fully satisfying answers in these forums and very seldom they come from ST employees. If you maintain an IDE you should have real experts and also have them post here on the forums. I have the impression that a simple test will already reveal many problems and documenting a few things would save others from breaking their projects. I was about to switch to VisualGDB a friend of mine uses very successfully and has no such problems as I have. But I decided to stay with CubeIDE because this is the official ST IDE. Now I am not sure if this was not a mistake.

[Pavel A.]

> Regarding the relative path issues: The sad thing is that these problems exist since Eclipse exists,

Relative paths are problem of any IDE but Eclipse CDT has a nice way to handle this,

Almost as nice as variables in makefiles. It has path variables and build variables.

They are not a problem, they are solution. Use them exactly as you would use variables in a makefile.

>  It is also amazing how few Eclipse related problems get fully satisfying answers in these forums and very seldom they come from ST employees.

Eclipse has very large community, SO, forums, bugzilla and so on. Everyone are welcome to these resources to learn about Eclipse and find answers.

However, IDE based on CMake (even Eclipse) would be better than CDT managed XML spaghetti.

-- pa

[Piranha]

Just follow my advice here:

https://community.st.com/s/question/0D53W00000hOmC4SAK/cannot-update-stm32cubeide-from-160-to-161-on-windows

Needless to say that EmBitz uses relative paths and moving/duplicating a project takes... just imagine it - a Cut/Copy and Paste operations on a project folder in a file system. What a magic!

[Cartu38 OpenDev]

@Piranha​ unfair & useless comment ...

Cannot compare apples and pears ...

[Piranha]

Having to do wild dances just for managing files and folders... Seriously? That is just terribly unproductive. The whole Eclipse's "Workspace" concept is broken by design. Even the Eclipse developers seem to start admitting it...

https://wiki.eclipse.org/Workspace4.0#Decouple_Workspace_from_Client.2FUI