I am currently developing for a ODROID esp32 device. Arduino is default environment for development (some people who wanted to go a "native" way did struggle...).
Basic library is espressif/esp32.
In addition to that I am using a TFT library which is working fine.
Now I want to use more parts of the hardware. For that there's support in the provided ODROID library which I currently don't use.
But if I enable it by including it into my sketch I'll get conflicts with the TFT library (which is required/preferred by me).
Both libs are properly installed. The tft lib is working fine w/o odroid and the odroid lib w/o tft lib is also working fine.
I simply tried to import just a part of the headers via "#include <utility/xxx.h>" (subfolder of odroid lib) but it could not be found.
(And copying it to sketch dir of course lead to lib not found...)
Normally I use "full" IDEs and write my own makefiles with setting up header and lib paths but here I want to do it "the Arduino way". Actually I know some ways to resolve the issue but I am searching for a "clean" and "Arduino" solution for that.
And another goal is to simply provide one sketch file (and not a bunch of file) and to use existing libraries as simple as possible (and without conflicts) in order to avoid as many issues as possible when the sketch is used by other people.
Thus my generic questions:
How are headers and libs searched for / how can it be configured? Does maybe some source file "hack" exist where you can specify custom defines and then include a header to extend search paths? Can you please point me to matching docs? I didn't find anything matching.
How are conflicts normally resolved with Arduino if you have a base lib and two optional libs with conflicts between the optional libs? E.g. by manually configuring paths?
If your answer would be something like "set up the code/lib by your own" then it would be fine. I just want to clarify on that.
How are headers and libs searched for / how can it be configured?
I can tell you how they are searched for, but since there's no way to configure it, I doubt the information would matter to you. The idea with Arduino is that it just automagically works so you don't even need to think about that stuff. Install the library, add the #include directive for the header file, and everything is taken care of.
The most control you get is that the #include "Foo.h" syntax will cause the current folder to be searched, followed by the include search path, whereas the #include <Foo.h> syntax only searches the include search path. That's just a standard feature of C++.
fwbergmann:
Does maybe some source file "hack" exist where you can specify custom defines and then include a header to extend search paths?
No.
fwbergmann:
How are conflicts normally resolved with Arduino if you have a base lib and two optional libs with conflicts between the optional libs? E.g. by manually configuring paths?
I don't know what you mean by "conflict". If there is a conflict in the code (such as a name collision), then you just need to fix the code.
If you mean a filename collision, the Arduino IDE does have a system for trying to find the library. What I mean is you might have two libraries installed that have a file named TFT.h. The IDE will try to pick the best matching library, based on a few different factors. When it picks the wrong one, you can sometimes do some things to influence the IDE to pick a different library. I can provide more information on that if it's the type of collision you're wondering about.
When I saw the first build output I was "in fear" of such an automation.
It makes sense for target users. Actually it is awesome work and offers an easy start for new developers. Thanks to everyone who made MC development that easy. (I remember good ole times with UV lamps for EPROMs and expensive cross assemblers...)
When I am more familiar with all the libs used I can still go the makefile way.
I don't know what you mean by "conflict". If there is a conflict in the code (such as a name collision), then you just need to fix the code.
Structs and more were redefined.
When it picks the wrong one, you can sometimes do some things to influence the IDE to pick a different library. I can provide more information on that if it's the type of collision you're wondering about.
No, it was not at link stage. The conflict was at compile stage because the TFT lib did same defines like the odroid headers.
I did solve it by simpling avoiding the odroid lib and doing hw access by myself (I actually didn't need the "full" class provided).
Your answer was great. It exactly answered the assumption I had as Arduino novice.
Thank you.
