User Include Directories?

Comments

3 comments

  • Avatar
    David Porter

    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

    0
    Comment actions Permalink
  • Avatar
    David Porter

    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.

     

    0
    Comment actions Permalink
  • Avatar
    Trahn Knee

    @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

     

     

    0
    Comment actions Permalink

Please sign in to leave a comment.