Last year I was playing with KDS 1.1.0, and I created a walkthrough for the httpsrv example to help others get going with the K64F. I'm now at a point with my project where I'm going to really start spending time with KDS, and the first thing I did was to upgrade to KDS 2.0.0, as well as KSDK 1.1.0. Unfortunately, I am not having much luck with the httpsrv example, specifically in the scenario where I am copying the example via Import into a different folder location.
When I do this, it seems that all of the dependency paths get mixed up. For example:
See all of the ../? There are way too many, and since my actual project directory is in a different branch of folders, there's no way to get to the necessary files from there.
First, it should be ${KSDK_PATH}, not ${ProjDirPath}/../../.... In addition, during the installation of KSDK, it asked me if I wanted to update the KSDK_PATH with the new folder location, and I said yes. But it didn't and the old path remained. Third, none of the Source files get copied over, so they have to be manually copied and added to the project. There are probably more, and if it's really confusing I will release a new walkthrough document once I have the sample working.
Just thought I'd give everyone and ChrisTango a heads-up, and also I'm interested if anyone else has had a similar experience, or if this is somehow user error.
Solved! Go to Solution.
I like the approach I am using right now to separate KSDK and my own applications in SVN. KSDK has its own folder that is separate from the rest of my source code, and I compile and check in changes with the related binaries as necessary. This means I can check out the KSDK to another computer (as long as KSDK_PATH is set) and just build my other projects without having to worry about the KSDK.
Yes, importing is a pain, so I only do it for the example projects. I import into my own application's workspace, and then modify the .project and .cproject files to fix the relative paths that get messed up during the import. That's pretty much all that needs to be done, and I haven't had any issues with the examples. My biggest problem was with C++ support, but since I've given up on that and have decided to use C from now on, I'm making a lot more progress on my app.
I guess I'm fortunate that I started getting serious with KDS after 2.0 came out. Sorry to hear about the problems going back and forth between 1.1 and 2.0! :smileysad:
FYI, I gave up on this project. While we pretty much got everything working, it's just too much of a pain in the neck if another developer has to get his particular system configured. I've ditched this approach in favor of just building everything in the KSDK_PATH location and symbolically linking to our SVN folder structure.
I think the KSDK_PATH is generally what's recommended, or "best-practice" from everything I've seen on these forums as well as Erich Styger's MCU on Eclipse tutorials. I have to say however, that once you open a project from 1.1.0 in 2.0, there is pretty much no going back - even if I want to open old projects back in 1.1, I unfortunately can't without a ridiculous amount of work. Unfortunately, I haven't had very much luck with importing old projects (1.1) into new workspaces under 2.0 either. The file dependencies/structures and even some of the names - such as "common" files, that were previously used are no longer there, so all of those includes need to be removed in order to build without error. The file structure for the default templates also changed for KDS/SDK projects. Argh...
I like the approach I am using right now to separate KSDK and my own applications in SVN. KSDK has its own folder that is separate from the rest of my source code, and I compile and check in changes with the related binaries as necessary. This means I can check out the KSDK to another computer (as long as KSDK_PATH is set) and just build my other projects without having to worry about the KSDK.
Yes, importing is a pain, so I only do it for the example projects. I import into my own application's workspace, and then modify the .project and .cproject files to fix the relative paths that get messed up during the import. That's pretty much all that needs to be done, and I haven't had any issues with the examples. My biggest problem was with C++ support, but since I've given up on that and have decided to use C from now on, I'm making a lot more progress on my app.
I guess I'm fortunate that I started getting serious with KDS after 2.0 came out. Sorry to hear about the problems going back and forth between 1.1 and 2.0! :smileysad:
More changes -- you will need to edit .cproject and replace all occurrences of PARENT-(number)-PROJECT_LOC + whatever relative path markers follow with something that makes sense and is relative to ${KSDK_PATH}. The linker general settings also point to incorrect locations and need to be adjusted.
I think I've figured out a solution to the problem. In posting this solution, I am hoping that someone out there will either realize what I had done wrong with my KDS installation, or the KDS team will see something that is a possible bug.
Ultimately, it looks like the .project has incorrect values in it. When I opened the .project file after importing ksdk_platform_lib_K64F12, it had entries like this:
<link>
<name>platform/adc16/drivers/fsl_adc16_common.c</name>
<type>1</type>
<locationURI>PARENT-4-PROJECT_LOC/platform/drivers/src/adc16/fsl_adc16_common.c</locationURI>
</link>
I haven't been able to figure out what PARENT-4-PROJECT_LOC refers do, but I do know from the Eclipse documentation that environment variables are allowed. So therefore, I should be able to use this:
<link>
<name>platform/adc16/drivers/fsl_adc16_common.c</name>
<type>1</type>
<location>${KSDK_PATH}/platform/drivers/src/adc16/fsl_adc16_common.c</location>
</link>
But that didn't work. After more digging, I found out that Eclipse doesn't support environment variables like this by default, but instead it has a feature called Linked Resources that can be used to support path variables. You can find this in Window -> Preferences -> General -> Workspace -> Linked Resources. I modified mine like this:
After I added that and reloaded my project, bingo! The file I located with ${KSDK_PATH} could now be opened in the editor.
It also turns out that if you make this modification to the "master" .project file found in the KSDK folder and then import it, the imported project works straight away.
The problem gets compounded in cases like httpsrv where several dependencies also need to get compiled. Importing ksdk_platform_lib_K64F12 has identical problems. I'm currently trying to understand the build process for eclipse as I am new at it, but I think the proper way to solve this problem is to understand the .project schema. If anyone has tips on using .project to either correctly do "virtual" links or perform file copies to the project folder, I would appreciate it! Meanwhile, hopefully google is good to me...
EDIT -- finally found the info on the project file: Help - Eclipse Platform