Inconsistent include path expansion in KDS3.0

[davepfaltzgraff]

I have taken a project and modified the include paths to use the KSDK_PATH environment variable. This was done at the Project=>Properties level. When I compile, several of the files are OK, but then I get to one file where the include paths passed to the compiler are from the previous version. A portion of the console output is shown below. Note how the first file shows the paths as being expanded to "C:\Freescale\KSDK_1.2.0/..." but in the second case the paths are expanded to "../../.." I have eliminated some of the output for brevity.

I have tried a clean and a refresh before recompiling. This has not fixed the problem. I'm open to suggestions.

Thanks

======

'Building file: C:/Freescale/KSDK_1.2.0/examples/frdmk22f/pin_mux.c'

'Invoking: Cross ARM C Compiler'

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Os -fmessage-length=0 -fsigned-char

-ffunction-sections -fdata-sections -Wall  -g -D_DEBUG=1 -D_AEABI_LC_CTYPE=C -D__STRICT_ANSI__=1 -DCPU_MK22FN512VLH12

-DFRDM_K22F -DFREEDOM -DFSL_RTOS_MQX -DUSB_DISK_ENABLE=1

-I"C:\Freescale\KSDK_1.2.0/examples/frdmk22f"

-I"C:\Freescale\KSDK_1.2.0/platform/CMSIS/Include"

-I"C:\Freescale\KSDK_1.2.0/platform/devices"

...(SNIP)

-I"C:\Freescale\KSDK_1.2.0/middleware/filesystem/fatfs"

-I"C:\Freescale\KSDK_1.2.0/middleware/filesystem/fatfs/fsl_usb_disk" -

std=gnu99 -fno-strict-aliasing -Wno-format  -fno-common  -ffreestanding  -fno-builtin  -mapcs

-MMD -MP -MF"board/pin_mux.d" -MT"board/pin_mux.o" -c

-o "board/pin_mux.o" "C:/Freescale/KSDK_1.2.0/examples/frdmk22f/pin_mux.c"

'Finished building: C:/Freescale/KSDK_1.2.0/examples/frdmk22f/pin_mux.c'

'Building file: C:/Freescale/KSDK_1.2.0/platform/utilities/src/fsl_debug_console.c'

'Invoking: Cross ARM C Compiler'

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Os -fmessage-length=0 -fsigned-char

-ffunction-sections -fdata-sections -Wall  -g -D_DEBUG=1 -D_AEABI_LC_CTYPE=C -D__STRICT_ANSI__=1 -DCPU_MK22FN512VLH12

-DFRDM_K22F -DFREEDOM -DFSL_RTOS_MQX -DUSB_DISK_ENABLE=1

-I../../../../../../../../../../rtos/mqx/lib/frdmk22f.kds/debug

-I../../../../../../../../../../rtos/mqx/lib/frdmk22f.kds/debug/config

-I../../../../../../../../../../rtos/mqx/lib/frdmk22f.kds/debug/mqx

-I../../../../../../../../../../rtos/mqx/lib/frdmk22f.kds/debug/mqx_stdlib

...(SNIP)

-I../../../../../../../../../../platform/hal

-I../../../../../../../../../../platform/drivers/src/i2c

-I../../../../../../../../../../middleware/filesystem/fatfs

-I../../../../../../../../../../middleware/filesystem/fatfs/fsl_usb_disk

-I"C:\Freescale\KSDK_1.2.0/rtos/mqx/mqx/source/bsp"

-I"C:\Freescale\KSDK_1.2.0/rtos/mqx/mqx/source/psp"

-I"C:\Freescale\KSDK_1.2.0/rtos/mqx/mqx/source/psp/cortex_m"

-I"C:\Freescale\KSDK_1.2.0/rtos/mqx/mqx/source/psp/cortex_m/compiler/gcc_arm"

-I"C:\Freescale\KSDK_1.2.0/rtos/mqx/mqx/source/nio"

-I"C:\Freescale\KSDK_1.2.0/rtos/mqx/mqx/source/nio/drivers/nio_serial"

-I"C:\Freescale\KSDK_1.2.0/rtos/mqx/mqx/source/nio/drivers/nio_tty"

-I"C:\Freescale\KSDK_1.2.0/rtos/mqx/mqx/source/nio/drivers/nio_dummy"

-std=gnu99 -fno-strict-aliasing -Wno-format  -fno-common  -ffreestanding  -fno-builtin  -mapcs

-MMD -MP -MF"utilities/fsl_debug_console.d" -MT"utilities/fsl_debug_console.o" -c

-o "utilities/fsl_debug_console.o" "C:/Freescale/KSDK_1.2.0/platform/utilities/src/fsl_debug_console.c"

[joeseymour]

Is it possible that there are file-specific properties applied to the file that's building with the old settings? Files/directories with their own properties are marked with a spanner/wrench in the project explorer.

CDT/User/FAQ - Eclipsepedia

Setting Up Include Paths and Macros for C/C++ Indexer

[Alice_Yang]

Hello David,

Could you please tell us what is the main aim , or what function you want to realize ?

Or which situation you think is right ?

BR

Alice

[davepfaltzgraff]

Hi Alice,

My basic intent is to be able to take one of the examples and move it to a new project to work on it. I think the examples provided are good, but I'd like to be able to modify the application specific doe without making any changes to the original. There are two reasons for this. First, the original is always there as a backup to check when something goes wrong. Second. as the new project matures and moves toward production, I need to be able to check it into my VCS.

There has been a lot of dialog on this. For my specific conversation, see How to move from a FRDM-K22F demo to a new application  I have been able to replicate this with KSDK 1.2 and even extended it to the point where only the application code gets moved.

Going back to my original posting, May 20th, I'm not sure how I addressed that specific issue and don't even recall which example I was working on at the time. It may be that there was a "wrench" in the works (see Joe's posting), but I am unable to replicate the problem now. When it takes more than a day or so to get a response, I have to move on. Where I go may not be an optimal path, but it is motion.

To answer your second question of "which is right", what I'd like to see is that all examples get set up using the ${KSDK_PATH} and ${PROJ_DIR_PATH} constructs and get rid of all the relative path "../../../../../../" use. As long as the relative path construct is used, the end users (like me) are either forced to remain within the file structure defined by Freescale or go through the tedious editing as outlined in the referenced link. By allowing users to quickly and easily separate the example from the Freescale file structure and move it to a new project, you would be facilitating wider use of the KSDK.

Another advantage of using the ${KSDK_PATH} construct is that when a new version of KSDK is released, I only need to change the definition in the project and recompile. In that way, I don't need to start the project extraction process all over again and then add my application code to it. (Upgrades should not be painful.)

The attached file is the example that I worked through. You should be able to unzip it to anywhere on your disk and then import it into KDS, compile and run. I know that's a bold statement, but so far it's worked for me.

Thanks.

[davepfaltzgraff · Accepted solution]

After posting the project example on June 2nd, I went to another PC and tried it. To my dismay, it didn't work as cleanly as expected!

The problem was with some functions not being found during the final link. So, my thought was that maybe I was missing some libraries. After going through the list and verifying that all the libraries were there and recently compiled, I finally took a close look at the command line being passed to the linker Sure enough, there was the problem.

The entry for Project->Properties->C/C++ Build->Settings->Cross ARM C Linker->General was:

     "${KSDK_PATH}/platform/devices/MK22F51212/linker/gcc/MK22FN512xxx12_flash.ld"

The entry for Project->Properties->C/C++ Build->Settings->Cross ARM C Linker->Miscellaneous was:

     "${KSDK_PATH}/rtos/mqx/lib/frdmk22f.kds/debug/mqx/lib_mqx.a"

     ... etc.

All looked good, but the expansion for the KSDK_PATH was inconsistent. In the case of the General category (the .ld file), it was correct, but for those under the Miscellaneous category, it was expanded to "C:\Freescale\KSDK_1.1.0" - the old value. This caused the linker to look into the old libraries which did not have those functions defined.

It was only after several retries of refresh and recompile that it cleaned itself up and I got a clean compile.

My recommendation: When this type of thing happens, try using a new workspace.

I'm guessing that there are remnants in the workspace that hang around just to confuse the programer. Now, if I could only remember what I was trying to do when I got into this mess.