Skip to main content
Arduino

Return to Answer

deleted 1416 characters in body
Source Link
Sean Walton
Sean Walton
  • 91
  • 1
  • 3

Okay, you've knuckled under and decided that the only course is to follow the rules. There's a little gotcha, and this gotcha is, again, nonintuitive. Look at the files you include that reside the ./libraries directory. There are none. They are all directories. Yet, you include files in your source. The files you include reside in one of those directories, and you refer to them as if they were all in one directory. Aside from name space collisions that can take place, finding the right place for your files takes a little more. So, you will have to follow the rules, again: To get an isolated path for your files, you have to go one level deeper.

For example, suppose I have a library file "test.hpp". If I want to use it, I have to place it in a directory I created. (Remember, you files under ./libraries are accessed one relative level up, "../".) So, I create a directory "./locallibs" under "./libraries". You would expect that from there I can use #include "locallibs/test.hpp". Sorry, doesn't work that way. It is visible as if the directory didn't exist, because all the contents of those directories are flattened. The purpose of using directories is to organize and to avoid name space collisions. Therefore, to do it properly, you have to add yet another directory "mylib" ("./libraries/locallibs/mylib"). NOW, you can use #include "locallibs/mylib/test.hpp", I recommend using <> instead.

In conclusion there is no clean way of making your own tree of tools in a nearby directory. The only course is to commit your work in the Arduino library and be aware of those rules as well.

Okay, you've knuckled under and decided that the only course is to follow the rules. There's a little gotcha, and this gotcha is, again, nonintuitive. Look at the files you include that reside the ./libraries directory. There are none. They are all directories. Yet, you include files in your source. The files you include reside in one of those directories, and you refer to them as if they were all in one directory. Aside from name space collisions that can take place, finding the right place for your files takes a little more. So, you will have to follow the rules, again: To get an isolated path for your files, you have to go one level deeper.

For example, suppose I have a library file "test.hpp". If I want to use it, I have to place it in a directory I created. (Remember, you files under ./libraries are accessed one relative level up, "../".) So, I create a directory "./locallibs" under "./libraries". You would expect that from there I can use #include "locallibs/test.hpp". Sorry, doesn't work that way. It is visible as if the directory didn't exist, because all the contents of those directories are flattened. The purpose of using directories is to organize and to avoid name space collisions. Therefore, to do it properly, you have to add yet another directory "mylib" ("./libraries/locallibs/mylib"). NOW, you can use #include "locallibs/mylib/test.hpp", I recommend using <> instead.

In conclusion there is no clean way of making your own tree of tools in a nearby directory. The only course is to commit your work in the Arduino library and be aware of those rules as well.

In conclusion there is no clean way of making your own tree of tools in a nearby directory. The only course is to commit your work in the Arduino library and be aware of those rules as well.

added 1452 characters in body
Source Link
Sean Walton
Sean Walton
  • 91
  • 1
  • 3

Okay, you've knuckled under and decided that the only course is to follow the rules. There's a little gotcha, and this gotcha is, again, nonintuitive. Look at the files you include that reside the ./libraries directory. There are none. They are all directories. Yet, you include files in your source. The files you include reside in one of those directories, and you refer to them as if they were all in one directory. Aside from name space collisions that can take place, finding the right place for your files takes a little more. So, you will have to follow the rules, again: To get an isolated path for your files, you have to go one level deeper.

For example, suppose I have a library file "test.hpp". If I want to use it, I have to place it in a directory I created. (Remember, you files under ./libraries are accessed one relative level up, "../".) So, I create a directory "./locallibs" under "./libraries". You would expect that from there I can use #include "locallibs/test.hpp". Sorry, doesn't work that way. It is visible as if the directory didn't exist, because all the contents of those directories are flattened. The purpose of using directories is to organize and to avoid name space collisions. Therefore, to do it properly, you have to add yet another directory "mylib" ("./libraries/locallibs/mylib"). NOW, you can use #include "locallibs/mylib/test.hpp", I recommend using <> instead.

In conclusion there is no clean way of making your own tree of tools in a nearby directory. The only course is to commit your work in the Arduino library and be aware of those rules as well.

In conclusion there is no clean way of making your own tree of tools in a nearby directory. The only course is to commit your work in the Arduino library.

Okay, you've knuckled under and decided that the only course is to follow the rules. There's a little gotcha, and this gotcha is, again, nonintuitive. Look at the files you include that reside the ./libraries directory. There are none. They are all directories. Yet, you include files in your source. The files you include reside in one of those directories, and you refer to them as if they were all in one directory. Aside from name space collisions that can take place, finding the right place for your files takes a little more. So, you will have to follow the rules, again: To get an isolated path for your files, you have to go one level deeper.

For example, suppose I have a library file "test.hpp". If I want to use it, I have to place it in a directory I created. (Remember, you files under ./libraries are accessed one relative level up, "../".) So, I create a directory "./locallibs" under "./libraries". You would expect that from there I can use #include "locallibs/test.hpp". Sorry, doesn't work that way. It is visible as if the directory didn't exist, because all the contents of those directories are flattened. The purpose of using directories is to organize and to avoid name space collisions. Therefore, to do it properly, you have to add yet another directory "mylib" ("./libraries/locallibs/mylib"). NOW, you can use #include "locallibs/mylib/test.hpp", I recommend using <> instead.

In conclusion there is no clean way of making your own tree of tools in a nearby directory. The only course is to commit your work in the Arduino library and be aware of those rules as well.

Source Link
Sean Walton
Sean Walton
  • 91
  • 1
  • 3

Okay, here is how it works, and I checked it to make sure.

Sure you can use hard paths, but every programmer hates using hard paths. They are not portable at all, and they lock your program in place. You use soft or hard links to the files in the project (look up the man pages on "ln"). But,... talk about ugly! So the question is how to do it "correctly"? The key is learning with what parameters and in what path the C/C++ compiler runs.

You will find the conclusion is NOT intuitive at all. Cutting to the chase: relative paths don't work correctly. Now, why?

But first, let me explain why anyone would want to place program files outside the project directory. Programmers like writing program classes, structs, methods, functions, macros, etc., once. As soon as the programmer solidifies the program fragment, he/she wants to put the files in a common tree and move on. Every program thereafter could use that private library. Also, by having the files in a central place, you won't have multiple copies and versions of each. One private library for many private programs.

As of 1.6.13 (Teensy does not yet support 1.8.*), relative includes start from the library, not your directory. It appears that the ano-to-C filter (remember that Arduino does a "conversion" to the target then calls the C/C++ compiler) starts where you installed your Arduino tree. In my case, I installed in "~/bin/arduino". Teensy's home is "./hardware/teensy". The entire home path for the libraries is "~/bin/arduino/hardware/teensy/avr/libraries" where you will find all the support program trees.

In a source file, the '#include "test.hpp"' statement correctly picks the file from your current directory. HOWEVER, if you use '#include "../test.hpp",' the include path does not start in your project directory. Instead it starts in "./libraries"! So the resulting path is:

#include "../test.hpp" ==> ./arduino/hardware/teensy/avr/libraries/test.hpp

In conclusion there is no clean way of making your own tree of tools in a nearby directory. The only course is to commit your work in the Arduino library.