Solution shared for problems when building default C++ application

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Solution shared for problems when building default C++ application

Jump to solution
770 Views
dave408
Senior Contributor II

This is just an FYI for anyone trying to get C++ projects working and for the KSDK team.  I've been struggling with the (I think) misleading g++ error message "fatal error: no input files".  It turns out that when you #include fsl_device_registers.h, you'll also end up #including processor-specific includes, depending upon which processor you have added to your preprocessor definitions.  I believe the problem with this file is that it then #includes (in my case) device/MK64F12/MK64F12.  While not necessarily a big deal, this file does appear in two different locations on the computer -- one in the KSDK_PATH, and the other in your project folder if you used the KDS New Project wizard.  Depending upon which one you pick, and what other -Includes locations you have in your toolchain settings, you may compile successfully or get that "no input files" error.

 

Hopefully this helps someone out.  Oh, and BTW there is also an Eclipse bug that also bit me -- you have to use the CDT variable ${ProjDirPath}.  ${PROJECT_LOC} will not work.

Labels (1)
Tags (3)
0 Kudos
1 Solution
543 Views
BlackNight
NXP Employee
NXP Employee

The Kinetis SDK sets a Windows environment variable named KSDK_PATH. Is this variable set on your system?

You can find out with launching the cmd.exe and typing

set KSDK_PATH

and it should list its value if it is defined.

Otherwise probably you do not havie the Kinetis SDK installed, or that variable somehow did not got defined?

View solution in original post

0 Kudos
5 Replies
543 Views
Rick_Li
NXP Employee
NXP Employee

Hi Dave,

Thanks a lot for your sharing.

It's helpful, but when I tried ${PROJECT_LOC}, it also works on my side!

0 Kudos
543 Views
dave408
Senior Contributor II

HI Yong, thanks for letting me know.  That's very strange!  But then again, lots of strange things happen with eclipse that I don't understand.  I can take a project and check it out to three different computers.  Although it builds on one computer, it may not build on one of the others.  It seems like it's possible that eclipse has settings stored elsewhere that resolve file locations properly.

0 Kudos
543 Views
dave408
Senior Contributor II

KDS drives me crazy sometimes.  It's just happened to me again.  I checked in a brand-new project this afternoon, then checked it out on a clean system with a brand new installation of KDS, KSDK, and the eclipse update.  It built there just fine.  Now I'm at home and I've checked out the project and it doesn't compile.  As it turns out, when I go to the toolchain settings, I can very clearly see that the ${KSDK_PATH} linked location variable I created is not working. All of my -I arguments are missing "C:\Freescale\KSDK_1.1.0".  So, for example, instead of -I"C:\Freescale\KSDK_1.1.0\rtos", I get -I"\rtos".  Can anyone explain why this is the case?

0 Kudos
544 Views
BlackNight
NXP Employee
NXP Employee

The Kinetis SDK sets a Windows environment variable named KSDK_PATH. Is this variable set on your system?

You can find out with launching the cmd.exe and typing

set KSDK_PATH

and it should list its value if it is defined.

Otherwise probably you do not havie the Kinetis SDK installed, or that variable somehow did not got defined?

0 Kudos
543 Views
dave408
Senior Contributor II

Hi Erich, you are correct, thanks very much.  I didn't even bother to check that because my other projects that use KSDK_PATH were previously working.  I can't explain how the variable disappeared, but on this particular computer that has KSDK installed, KSDK_PATH is no longer defined!

I guess this is kind of like electronics.  Even if you think something is as it should be, you still have to remember to check power and ground.  :smileyhappy:

0 Kudos