Handling dependencies that use the same header file names

1

Is there an option to require a package/dependency name in #include statements?

Say my dependency has a following structure:

include/
+ Color.h

Where Color.h has a very simple class that is fully declared in a .h file alone.

Now in my project that uses this dependency I normally should include it with:


#include <Color.h>

But I get errors because project has also a dependency on FastLED which also has a Color.h file.

It would be much better if PlatformIO required me / gave the option to use more explicit references, like:


#include <Color/Color.h>// My custom lib
#include <FastLED/FastLED.h>// My custom lib

I went though the PIO docs but no information on how to achieve this. This is even bigger problem when some of my libs have class Base.h.

2

Similar thing used to happen with the Time library because someone unfortunately called it… well… time.h … not the smartest of moves, calling it the same same name as a standard library… :open_mouth:

What about using "" instead of <> …

Although PlatformIO does pre-processing itself for the Library Dependency Finder, it should still be following these rules? Search Path (The C Preprocessor)

3

Unfortunately, using double quotes will not cut it - as this is not a local file in the project but a dependency. So I (believe I can’t / don’t) know exact file location.

I’m still facing this issue from time to time.

4

As in it’s installed by the library manager? Yeah, that would be an issue… as AFAIK the naming is pretty consistent - library name + ID, but there’s nothing to stop it from changing, so it’s not reliable enough to use this way.

Unfortunately the only real option at present I know of is to not use the same name as another include, which is a more generic C++ issue, rather than anything PlatformIO specific.

5

In my non-PlatformIO projects, I use #include “[libname]/[filename.h]” to avoid a global namespace. This will probably be an issue for me to when I transition to PlatformIO.

Requring all libraries to use unique header file names would be naive.

6

thanks for thoughts you guys. @pfeerick just to ensure I get you right (as cpp lib management is a little outside of my expertise):

Do I get you correctly that you suggest that using lib name + ID would fail in case the library author change library name? I believe these are extremely rare cases, and if someone does that it should be clearly communicated and people should simply use the new library.

Based on PlatformIO Registry library, something like:

#include <ArduinoJson+64/ArduinoJson.h>

Sounds good to me. Although version without ID still sounds more natural.

7

No, not naive, just a very well known issue if you’ve used more than a few third party libraries and had namespace collisions, the more famous one being the decision by one library writer to call their library header Time.h … which works perfectly fine on a case-senstive filesystem… not so well on Windows, as it then collides with the standard time.h… hence it’s now TimeLib.h… oops!

@m_lewand Doesn’t look like that will work. Given the example of the the full relative path to say the onewire library when included in a main.cpp located in \src:

../.pio/libdeps/Sensor 1/OneWire_ID1/OneWire.h

So that’s one level up form \src, in the pio/libdeps/env-name/LibName_ID# folder. Meaning it’s subject to change with environment name changes or renaming of the library (not often, but it happens, so need to be aware of that possibility). I would have liked #include <OneWire_ID1/OneWire.h> or #include "OneWire_ID1/OneWire.h" to work… but sadly they don’t… probably .pio/libdeps/Sensor 1 is not in the include path. You need to use the full relative path as shown above, i.e. #include "../.pio/libdeps/Sensor 1/OneWire_ID1/OneWire.h", for it to work. Any other partial path variant seems to break, both IntelliSense and on compile.