I have several c programs that need the "KflopToKMotionCNCFunctions.c" file. Since I store my C programs in a different location than within the c:\KMotion434 directory, I have been using the full path as #include "C:/KMotion434/C Programs/KflopToKMotionCNCFunctions.c"
However, the also usually needed #include "KMotionDef.h" is able to find the file without the path. This behavior is the only reason I even post on this issue. Note I am not much more than an amateur programmer lacking a good portion of the knowledge of the C file and data structure. That said, I assume I could do something like add a path somewhere to allow my programs to find the needed file with only #include "KflopToKMotionCNCFunctions.c".
Any advice is appreciated.
#including KflopToKMotionCNCFunctions.c and others
Moderators: TomKerekes, dynomotion
- TomKerekes
- Posts: 2679
- Joined: Mon Dec 04, 2017 1:49 am
Re: #including KflopToKMotionCNCFunctions.c and others
Hi MadTooler,
There isn’t a customizable include path. The compiler looks: In the same directory as the source file or in the DSP_KFLOP directory of the install directory. KMotionDef.h should remain within the install directory so the one used matches the firmware in use.
You might copy other utility files used by your code into the same directory as your code.
There isn’t a customizable include path. The compiler looks: In the same directory as the source file or in the DSP_KFLOP directory of the install directory. KMotionDef.h should remain within the install directory so the one used matches the firmware in use.
You might copy other utility files used by your code into the same directory as your code.
Regards,
Tom Kerekes
Dynomotion, Inc.
Tom Kerekes
Dynomotion, Inc.
Re: #including KflopToKMotionCNCFunctions.c and others
Thanks, Tom. That answers my question.
That makes sense. I have left KMotionDef.h alone. My issue has only been with KflopToKMotionCNCFunctions.c. Using the path at #include works for me.
BTW, not sure if it is suppose to, but #including KflopToKMotionCNCFunctions.c throws a compile error occasionally when #include KMotionDef.h is not called from a line prior. The only time I have noticed it failing when it is written on a line after is where I have one c program including another. The includes in the included c program are the finicky ones.
That makes sense. I have left KMotionDef.h alone. My issue has only been with KflopToKMotionCNCFunctions.c. Using the path at #include works for me.
BTW, not sure if it is suppose to, but #including KflopToKMotionCNCFunctions.c throws a compile error occasionally when #include KMotionDef.h is not called from a line prior. The only time I have noticed it failing when it is written on a line after is where I have one c program including another. The includes in the included c program are the finicky ones.
Re: #including KflopToKMotionCNCFunctions.c and others
Includes are read in order, so having KMotionDef.h after KflopToKMotioncCNCFunctions.s c will throw an error, as the ...Functions.c relies on code in the KMotionDef.h file, so if the KMotionDef.h file hasn't been read first, then the compiler will find unknown functions/constants in the ..Functions.c and throw an error.MadTooler wrote: ↑Mon Nov 12, 2018 5:50 pmBTW, not sure if it is suppose to, but #including KflopToKMotionCNCFunctions.c throws a compile error occasionally when #include KMotionDef.h is not called from a line prior. The only time I have noticed it failing when it is written on a line after is where I have one c program including another. The includes in the included c program are the finicky ones.
Re: #including KflopToKMotionCNCFunctions.c and others
Thanks, Moray.
I am aware of what the order of execution of includes should do. My initially poor ordering of the includes was due to sloppy practices. My note reflects a somewhat odd behavior where the compiler didn't seem to care if I had the includes in the wrong order unless it was within a c program that I was then including within another c program. Seems strange that it hasn't complained about the main program too.
I am aware of what the order of execution of includes should do. My initially poor ordering of the includes was due to sloppy practices. My note reflects a somewhat odd behavior where the compiler didn't seem to care if I had the includes in the wrong order unless it was within a c program that I was then including within another c program. Seems strange that it hasn't complained about the main program too.