0.13.0 does not find include file, 0.12.1 does

[ArminJo]

Bug Report

Here the error

/home/runner/work/ServoEasing/ServoEasing/examples/LightweightServoExample/LightweightServoExample.ino:28:10: fatal error: LightweightServo.h: No such file or directory
 #include "LightweightServo.h"

is with cli 13.0

This is the same situation, the only change is the different cli version 12.1

[per1234]

Thanks for the report @ArminJo!

Here's a more minimal demonstration of the bug:

$ arduino-cli lib install Ethernet  >/dev/null
$ mkdir /tmp/Foo
$ printf "#include <EthernetUdp.h>\nvoid setup() {}\nvoid loop() {}\n" > /tmp/Foo/Foo.ino
$ arduino-cli compile -b arduino:avr:uno /tmp/Foo
C:\Users\per\AppData\Local\Temp\Foo\Foo.ino:1:10: fatal error: EthernetUdp.h: No such file or directory
 #include <EthernetUdp.h>
          ^~~~~~~~~~~~~~~
compilation terminated.
Error during build: exit status 1

There is a bug in the way the includes field of library.properties works. Even though that field is only intended to customize the #include directives inserted into the currently open sketch by the Arduino IDE's Sketch > Include Library feature, what it now does is actually defines the header files visible to Arduino CLI's library discovery system!

The bug was introduced by e6f1947

The ServoEasing library has this includes field:
https://github.com/ArminJo/ServoEasing/blob/4436e46e211c0f5e445c5b4d57b9c142b382b552/library.properties#L9

includes=ServoEasing.h

The example sketches that are compiling in your CI run are those that use ServoEasing.h in their #include directives.

The example sketch that fails is the one using LightweightServo.h in its #include directive, because this file does not match the includes field in library.properties.

[ArminJo]

Thanks a lot per1234 🥇
I checked the specification, but there was no note about the new behavior.
But I can live with it, I deleted the includes field. 😉
Thanks again and have a nice weekend.
Armin

[per1234]

@ArminJo I hope you won't mind that I reopen this.

We should use this issue to track the bug until the issue has been resolved.

Even if this was an intentional change, it would need to be clearly documented in the library specification and the 0.13.0 release notes. So, no matter what, some action needs to be taken and we may forget about it without an open issue.

[Legion2]

Ok, when this was an intended change what is now the purpose of the include field in the library.properties file?
Because I think exposed API ≠ required API. For example, a library exposes two APIs A.h and B.h which are conflicting. So one don't want to include both in a sketch but the Arduino IDE will add both.

[per1234]

when this was an intended change

I'm sorry if my comment caused confusion @Legion2. From reading the commit message, I don't at all think this was an intended change. I'm sure it was an unintended change that can be considered a bug.

However, I didn't have any involvement in the project, so I can't say that for certainty. What I can say for certainty is that if this is a bug it will be fixed and if it was an intended change the new behavior will be clearly documented.

Because I think exposed API ≠ required API. For example, a library exposes two APIs A.h and B.h which are conflicting. So one don't want to include both in a sketch but the Arduino IDE will add both.

I think you make a good point. You provided a good example of how this might occur in #934 (comment):

the library "Corsair Lighting Protocol" only declares a single header file which is fine for normal users
(https://github.com/Legion2/CorsairLightingProtocol/blob/82c434f6fb2177faccde82b2e41e5210b009382a/library.properties#L10).
But for other uses cases other headers must be used, which are not declared by the library because they should not be used when a user adds the library in the Arduino IDE to the sketch.