Reading the Nordic SDK issue, let's expand the topic as in the title.I can't be the only one frustrated past anger at how SDKs make code and project portability from tricky to impossible. If you copy a project in Visual Studio it has links to the origin I have yet to cut properly. Copying projects in NXP CodeWarrior isn't as bad, but I've found only One way to do it. ST Visual Development has been the best I've used, but I've only done 3 projects in it so far.

My point is opening a discussion about how to cleanly copy and manage multiple versions of projects in various SDKs. I've spent Days trying to clone a project in Visual Studio and never could get rid of the links.

This is why I do most of my embedded development that uses proprietary SDKs in virtual machines if at all possible. Not only can I archive the entire development environment and re-run it later if necessary, I can also 'copy' the project by cloning the entire virtual machine as the starting environment for a new project. It's as if the software engineers at hardware companies had never heard of current practices in software development such as version control and modular architectures.

Yes, when I used the Lantronix XPort they distributed their SDK in the form of a VMware linux image. Seems kind of cumbersome for everyday lighweight project use, but works very well for the reasons you mention. PC hardware has gotten to the point where a typical system has enough CPU and memory to provide decent performance in a VM.

Microsemi (now Microchip) demo projects were always distributed as a tarball that was supposed to be unpacked at the top of the filesystem tree to avoid overly long paths in Windows. Yuck, and they would still have absolute path references that had to be fixed. Requests to keep all project path references relative fell on deaf ears, perhaps it isn't something you can do easily (if at all) in Windows.

Along this line, I’ve been experimenting with Docker and VSCode as a build environment. VSCode has a remote development option, so I can edit the sources in my host OS and have then compiled by the Linux Docker container in the background. The Docker container is basically just a Linux shell (no GUI) with compiler and build system installed, so it’s very light-weight.

As for version control, the Docker image is built from a recipe in a plain text file and VSCode settings are written in JSON so it’s trivial to include these in the project tree.

I agree with the part of using Docker and VSCode, I'm trying to do something similar with PlatformIO.
I hope this is sort of one of the better ways to do this in the new "standard" so to speak, for embedded.

I use Keil's (owned by ARM) MDK for Cortex development IDE and have been asking for a cloning function for years. In the end I wrote my own (in VB6 because it's based on an earlier effort)  - they don't document the XML files that contain the project data but there are only two of them and they were not that hard to unpick.

I get the feeling that most suppliers of IDEs or SDKs are too keen on locking the cutomer in rather than helping to get the job done.

MK

I'm not referring to cross manufacturer mobility. You'd think a mfgr would make it easy to copy / clone projects as incentive to stay in their product family.

I think that the two are related - I only clone one Keil project to another. 

I can only think that gathering all the files into one place or making an easy to use index of them all or using a standard system makes it too easy to jump ship.

MK

I agree that the IDE manufacturers are keen on lock-in. If you're Keil, you don't want your customers jumping ship to Gnu or some other IDE vendor. That's not really a concern for the hardware (MPU) vendor: How many real embedded product lines--those optimized for a device family and then thrown over to Manufacturing with BOMs and ECOs and all that--have ever been ported wholesale to a new architecture (even for new follow-on projects) unless the MPU manufacturer stopped supporting the old one? However, the MPU manufacturers typically aren't software developers, so they use the third-party software vendors to develop their SDKs, and that's where the problems lie. MPU vendors that start with a Gnu base or do their own in-house SDK development tend to have much better support for version control, modular architectures, and other modern software/firmware practices that make using existing projects as the base for new ones easier.

Great observation, I couldn't agree more. Ideally someone would be able to commit just project source files and build recipe (project files, Makefiles, whatever) to a repository. Assuming I have all requisite tools and versions installed and in my path, I should be able to pull from the repository, build cleanly and use the output. With some IDEs and tool chains it works exactly this way, but it doesn't seem to be the common case.

Some IDEs or SDKs are really good about avoiding absolute path references and links that go outside the project tree. When they don't, sometimes fixing these issues is a manageable problem. Familiarity with the IDE/SDK is also an issue. The more complex IDEs and SDKs are generally the most cantankerous, it's almost as if the people who developed them embraced the notion that it was hard to design, it should be hard to use.

I developed the habit of always including a project README that details requisite tools and versions, build instructions and any special cloning/porting instructions.

I spent a lot of time using the Nordic SDK in 2014. We used IAR, they claimed support for Keil and IAR but Keil was clearly favored and IAR support was spotty. I got pretty good at editing project files to create working IAR projects from Keil projects. Not exactly the point you're addressing, but related. A nice, self-contained project setup based on easily editable text files is not only easier to copy, it is easier to port.

The goal is to wind up in a job environment where you're always originating your own designs and projects. Then these issues are usually someone else's problem!

It feels good to see that I'm not alone, unfortunately it also feels bad since it means there are other people struggling with something I believe it shouldn't be such a big problem.

For quite some time now, I've struggled with this, mainly for the part of starting a new project faster, reuse code (as smarter colleagues have said, modular architectures), and so on.

I'm fairly new to the embedded systems field, learned to program in avr-gcc and use avrdude and then avr studio, so jumping to very boilerplate stuff like Keil, was a very hard thing to do.

But, to the point.
What about PlatformIO?, I've been reading about it, since 2019 if I'm not wrong, and it seems very good at allowing some of this, not only cross vendor use, but to prepare something automated to start a new project with a certain configuration, the project JSON is way better documented (if at all) than other IDEs, it allows you to use the CLI side, or configure your own toolchains and even use different compiling configurations for the same target.

I'm looking for configure this, precisly to have a way faster form of reuse previous projects and configurations.