User Include Directories?
Hi,
I am having difficulties compiling an imported uVision example project exported from mbed, the project compiles correctly in both mbed and emBlocks. The problems I am experiencing is that of 'directories not found'. There may be other problems, but the compiler stops on the first error, although I set, 'continue on error flag' (it may have no choice but to stop). Also, there is something odd in the Solution.xml file, which identifies the Target as being a "STM32L152RD", rather than the RE version, which is the chip the project is based upon. I looked around in the RCW directories, and sure enough there is an RD file, but that is not that is being used on the nucleo-L152RE board. Is this ok? Or is it a problem? In any case here is one example of a not-found-directory, there are others such as the cmsis.h not found, yet that package is installed? I sure wish I could see a full (complete) compile/link tree. It would save a lot of time.
Reviewing Project Explorer
click Project xyz
click Project Properties
User Include Directories (displays a long line of directories, each terminated with a semicolon)
USER INCLUDE DIRECTORIES list:
$(TargetsDir)/CMSIS_3/CMSIS/Include
.
mbed
mbed/TARGET_NUCLEO_L152RE
mbed/TARGET_NUCLEO_L152RE/TOOLCHAIN_ARM_MICRO
mbed/TARGET_NUCLEO_L152RE/TARGET_STM
mbed/TARGET_NUCLEO_L152RE/TARGET_STM/TARGET_NUCLEO_L152RE
mbed/TARGET_NUCLEO_L152RE/TARGET_STM/TARGET_STM32L1
mbed/TARGET_NUCLEO_L152RE/TARGET_STM/TARGET_STM32L1/TARGET_NUCLEO_L152RE
Compiling the sample project reveals the following error:
1> C:/a_dev/Nucleo_blink_led/main.cpp:1:18: fatal error: mbed.h: No such file or directory
The missing file is located in a project subdirectory, and is located specifically in 'mbed', which is included in the above USER INCLUDE DIRECTORIES list, yet the compiler does not find it. Is there something I am missing?
Also what does the "period" do which is located at second line down at the top end of the list?
Thanks in advance
trahn
-
Trahn,
I can't speak to much of this, but the "period" (.) in the second line references the 'working directory'.
The lines (such as "mbed" and "mbed/TARGET_NUCLEO_L152RE" reference subdirectories of the working directory.
So if the working directory is "C:/a_dev/Nucleo_blink_led", then the "." line lists the directory "C:/a_dev/Nucleo_blink_led" as directory to search for include files. Similarly, the "mbed" line lists the directory "C:/a_dev/Nucleo_blink_led/mbed" and so-on.
Like the "period" (.), a "double period" (..) also has a special meaning. It references the "parent directory" of the working directory. The parent directory of "C:/a_dev/Nucleo_blink_led" is "C:/a_dev".
Expanding on this a bit, the line "mbed" could also be written as "./mbed" or "C:/a_dev/Nucleo_blink_led/mbed".
"mbed" and "./mbed" are "relative" references. They indicate the location in the directory structure relative to the working directory.
"C:/a_dev/Nucleo_blink_led", on the other hand is an "absolute" reference. It points to the same place in the directory structure no matter what the current working directory is.
"Absolute" references are most useful to point to files that are not specific to the current project... Files like CMSIS libraries.
"Relative" references are most useful to point to files specific to the current project. If you move (or copy) the project they won't point back to the files used by the original project. A header file "Main.h", for example, should always be a relative reference.
All this talk about a single period! I hope it helps. :-)
-Dave
-
One more thing...
I implied that the working directory is "C:/a_dev/Nucleo_blink_led". This may not be the case!
I have encountered development environments where the "working directory" was the location of the compiler (for example). In these cases the best thing to do is to have a symbol defined that refers to the root directory of your project.
"$(TargetsDir)" is an example of such a symbol.
I think for CrossWorks the working directory is the directory containing the .HZP file, so you are probably okay.
-
@David Porter,
Thank you for the info on the direcctory issue. Turns out that the problem was caused by spaces in the source project file that I imported. I suspect that the import string parser was not checking for spaces, but I understand that the matter will be addressed and corrected by RCW in a future release. Every little bit helps to create an excellent tool.
trahn
Please sign in to leave a comment.
Comments
3 comments