topic Re: How would you handle KSDK in a product as far as version control is concerned? in Kinetis Software Development Kit

How would you handle KSDK in a product as far as version control is concerned?

dave408 — Fri, 03 Apr 2015 15:20:33 GMT

My intention all along has been to keep KSDK in a separate folder in my SVN repository. The idea is to build the libraries needed (K64F, K22F, etc) once, and then link to the already compiled binaries in each of my firmware projects.

In my current mode of operation, I am actually creating test projects in "standalone" mode, which I believe just means that the KSDK files needed are copied to the local project's folder structure. The obvious advantages here are that it avoids the chances "folder reference hell" that I was going through for a little while when I was trying to figure out how to work around the bugs in KDS when trying to start by importing existing projects and copying them into my development workspace. I don't have to worry about finding all of the folder locations for each header file and manually adding each to my C/C++ toolchain's Includes section. It also means that I can maintain different KSDK settings for each project, if desired. Changes are obviously tracked by SVN.

One disadvantage is that certain changes might trigger a lengthy rebuild, which isn't such a big deal. Another, possibly bigger problem is that since the KSDK source files are local to the project, it enables / encourages others to tinker with the KSDK itself, which I'd rather leave as unmodified as possible. And the biggest problem has to do with scalability and the KSDK releases themselves. What I like about keeping KSDK in a separate, buildable working set is that when the KSDK is updated (for example, the upcoming update to 1.2 in Q2), I just have to update the folder, rebuild the libraries, and then all of my other projects will automatically receive the bug fixes. In the "standalone" case, I believe I'd be forced to manually copy the required files over, which doesn't scale well as the number of firmware projects increases.

So what are everyone's thoughts here? I don't think there's a right answer, and it probably depends on everyone's own situation, but I'd love to hear how you plan to handle KSDK versioning in your projects.

Re: How would you handle KSDK in a product as far as version control is concerned?

Jorge_Gonzalez — Fri, 10 Apr 2015 01:57:35 GMT

Hello Dave:

I am not handling KSDK with version control, but I wanted to share with you my insight about your question:

1. When KSDK is updated, you get a separate KSDK folder, so I guess the easiest way would be to remove the previous version folder/subfolders from your repository and add the new ones, apart from pointing your projects to the new library binaries.

2. With Processor Expert in the "Standalone" mode you would not have to copy files over from a new KSDK version. Instead you just update the Environment Variable when installing KSDK and Processor Expert will give you the option to upgrade the KSDK components (fsl_xxx) to the latest version when importing the project. With this you only re-generate code and Processor Expert will replace the local KSDK files with the new ones. Processor Expert development team is actively working towards easing migration from previous versions of KSDK.

Regards!

Jorge Gonzalez

Re: How would you handle KSDK in a product as far as version control is concerned?

dave408 — Fri, 10 Apr 2015 13:26:29 GMT

Thanks Jorge, I understand your points, and that upgrading from the current KSDK to future versions is supported by KDS/PEx. It does seem like standalone projects are a viable option as the components can be easily upgraded. However, having the KSDK libraries precompiled is still really nice from a speed standpoint. In addition, when there is one location for the KSDK source, bug fixes independent from FSL's work can be committed and immediately deployed to all firmware projects. I also don't want to encourage future developers here to make changes in a standalone project, because those improvements might not make it to the other devices. Having the KSDK under version control would help out there a lot.

That said, I also don't really expect to be making many changes to the KSDK, and instead would probably wait for the scheduled releases.

But should I create standalone projects now and then want to use KSDK source under version control, I should be able to just delete the SDK folder from the standalone projects and then add the linked folders in KSDK_PATH, right?

Re: How would you handle KSDK in a product as far as version control is concerned?

neilporven — Thu, 04 Feb 2016 21:44:54 GMT

Hi Dave & Jorge,

Currently, we are trying to build a library where we can store the KSDK as well as build a software library for the company to use.

We are thinking of having a NAS drive that can be shared among our software developers and in this drive have the library mentioned

above.

Currently, we are experiencing the same issues mentioned by Dave. If I develop a module and set PATHs to a specific project, then when

someone from our team wants to use it, its a mess! I have to guide them through linking PATHs, giving them folders.....etc.... and of course

there is something that is always forgotten in the process, burning hours of troubleshooting instead of developing...

I have two questions:

1. Do you see the NAS drive solution a good one or what do you recommend instead? If your using a NAS drive (any recommendations)?

2. Is there a video or document (in Kinetis SDK) that demonstrate how to handle version control?

I know that this was written a while ago, but I hope it can be re-instated.

Thank you,

Neil Porven

Re: How would you handle KSDK in a product as far as version control is concerned?

dave408 — Wed, 10 Feb 2016 22:02:27 GMT

Hi Neil, I think what you're doing could work. But first, I'll describe what I'm doing, which works fine for now.

I have KSDK 1.2 in an SVN repository. All developers pull from this repo onto their local machines. Their machines need to have the KSDK_PATH environment variable defined, and this points to whichever folder they have chosen for checkout. I modified all of my projects to use LINKED mode instead of STANDALONE. I believe this is defined in the .PE file, and I have another post here in the community that explains how I went about changing from standalone to linked mode.

Everything else (shared folders) are in the SVN repo as well, and the various firmware applications use relative paths so we don't have issues with different developer machines.

In your case, you could use the NAS and have your KSDK_PATH point to it. That said, I wouldn't recommend doing anything outside of some kind of source control, because developers will be able to change things willy-nilly, and then you could be in for a world of hurt.