#include directive syntax

Continuing the discussion from I keep getting an error when trying to compile my code:

This part:

means your library file is local (in the same folder as the sketch.ino)... I do not know where that is when using the cloud editor.

Not necessarily. It's where the system will first look; if the system can't find it there the system will look in the standard directories.

That is how I use the quotation marks... to tell ME that my file is not in the system libraries. Do you use "file.h" to reference a system library? That sounds like a hide-and-seek game bound to crash, rather than accepted file naming.

I have seen ________.___ and _______.___ and about twenty similar used in one build... which did not help me, but I got around it... as well as lllllll1.ll1 and 0000000o.ooo Back when programming was an art and job security was built in to the programs. Funny, but not fun.

Why would it crash? Some might want to keep the option open to inject the libraries locally in case there are incompatible changes in the future without changing their code.

Sure, some good programmers might want that. But is that what the first time posters are expecting? Put the files anywhere. Should convention be ignored?

Hey, I am all for the idea that programming does not need to follow a convention (so many ways to read a button, amirite?), and I encourage this line of thought so programming gets escorted out of engineering and put into institutions with finger painting, basket weaving, spoon bending, interpersonal communications, and all "Arts" degrees. I've had to nanny so many genius programmers who couldn't interact with humans, show to work within three hours of start time, turn a lab full of keyboards into yellow/brown bugger scrapers... and unwrapping their code to find the missing semi-colon, as tangled as the sticky hairballs stopping their keyboard keys from working... so yeah, Vive les Arts des Programmeux! : ) Nannies need jobs, too.

I prefer to blindly follow simple conventions that let others understand my poor coding. Maybe I will advance from beginner programmer one day. Probably not.

I have split the discussion about #include directive syntax to a dedicated topic so that this valuable and interesting discussion can continue freely while also being able to focus exclusively on the support request in the original topic.

Carry on.

It is worth noting that the #include directive in question is in a library, not in the sketch. In the case of an #include directive in library code, double quotes syntax is most correct when referencing a file within that library.

I wouldn't put it quite that way, but I agree with your sentiment. Use of inappropriate #include directive syntax is a pet peeve of mine. In the corpus of Arduino code, we will often see the two used completely at random, even completely inconsistently within a single code base.

The sloppiness arises from the fact that the developers can get away with using inappropriate syntax. However, the inappropriate use of angle brackets syntax for local files in libraries is problematic because it stops working when you bundle a library with a sketch.


There is an interesting detail to this specific case: anyone who is generally familiar with the workings of the Arduino sketch build system, but not with the quirks of individual boards platforms might have wondered about @J-M-L's reply in the other topic:

When using any of the official boards platforms created by the Arduino company, and even most 3rd party platforms, this suggestion would be nonsensical. The reason is that the platforms traditionally do not include the sketch folder in the compiler's "search path". So, when using a platform with the traditional configuration, although we can use #include directives with the double quotes syntax in the sketch code for files in the sketch folder, we can not reference files from the sketch in #include directives in library code (regardless of which syntax we use).

However, the "esp32" developers did something non-standard by configuring the platform to add the sketch folder path to the search path:

(note the "-I{build.source.path}")

(note the {compiler.cpreprocessor.flags} property reference)

https://arduino.github.io/arduino-cli/latest/platform-specification/#global-predefined-properties

The following automatically generated properties can be used globally in all configuration files:

[...]

  • {build.source.path}: Path to the sketch being compiled.

So in this case the library developer used the inappropriate syntax, since the file is not in the local path relative to the library.

Totally right.

I think I had read this would work for the reason you explained and had been abused. Wondered if that was for that library though.

--

EDIT

So I wanted to check... I went to see the source code.

➜ if you are on an ESP it does not include ext_nimble_config.h and this is likely only for the nRF platform which requires their arduino core to work and the ext_nimble_config.h file is right there

so my initial idea was not correct.

Now wondering if the cloud editor does set ESP_PLATFORM ?

adding in setup something like

#if defined(ESP_PLATFORM)
  Serial.println("OK ESP_PLATFORM is defined");
#else
  Serial.println("OOPS ESP_PLATFORM is NOT defined");
#endif

would clarify

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.