Include Arduino Libraries (SPI.h) with different core causes problems

[NicoHood]

I've installed the current dev version of my HID project. This uses a different Core.

I am not able to include the SPI.h library when the new core is selected. I am able to include it if I move it to the other libraries in the root of the installation instead of in hardware/arduino/avr/libraries. But if I save my sketch and open it again via double click it throws this error again.

There is a difference between starting a sketch via double click or opening a new IDE window and pasting the code. I noticed this several times in other cases.

#1st error
Build options changed, rebuilding all
sketch_jan24a.ino:46:17: fatal error: SPI.h: No such file or directory
compilation terminated.
Error compiling.

#moving lib, then double click and compile
ArduinoISP.ino:46:17: fatal error: SPI.h: No such file or directory
compilation terminated.
Error compiling.

Using 1.6 rc2, Windows 8.1 Update

This is my workaround:
NicoHood/HID@bff1b97

[ffissore]

@NicoHood is this still valid?

[NicoHood]

Yes. If you have 3rd Party AVR core it does not load the default arduino libraries. So I have to copy every library into my core as well and update it with new IDE releases as well.

Just use this sketch to test it:

#include "SPI.h"

void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly:

}

Edit: tested with nightly of today, now on linux64 bit

[matthijskooijman]

@NicoHood, I guess this means you have a core that consists just of platform.txt, boards.txt and variants, but not a cores directory? e.g. it uses the normal core files verbatim? If so, could you see if you can reproduce this using a minimal platform.txt and boards.txt?

If not, then I guess this is somewhat expected - if you create a custom core, with custom files, there is no guarantee whatsoever that the core-specific libraries from the standard arduino-avr core actually work on your core as well. In fact, I believe that in this case there isn't even any link to the arduino-avr core that the IDE can use to decide what libraries to use (consider that there might be more third-party avr cores installed that could be a candidate). For this case, the only solution I can imagine is explicitly "inheriting" libraries from a specified core, by using something like "use-libraries-from=arduino:avr" in your platform.txt (exact syntax probably needs tweaking).

[NicoHood]

2nd Option you mentioned. Is there such an option yet or was this just an Idea how to implement it in the future?

[matthijskooijman]

I don't think the option exists yet, this is just how I would consider implementing it. For now, copying (or symlinking on *NIX) seems the only option (but I'm not 100% sure).

[cmaglie]

Well, actually the feature exists, and the IDE picks the libraries from the referenced cores among the others, I've solved that in #1445 (and this is the commit: be30113).

As an example the attiny core https://github.com/damellis/attiny/tree/ide-1.6.x uses this feature (just tested and it works). Here the boards manager url just in case https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json

@NicoHood is that happening with your HID core? I'll take a look to see what's happening...

[NicoHood]

The attiny variant files uses the Arduino core. What I've done is to create a whole new core. And this lacks the libraries, it only looks in the new core for the libraries and thatswhy I have to dupe them. It would be nice to have a setting where you still can choose the default libraries but still use another core.

[cmaglie]

Ahhh, ok now I see. IMHO this is the correct behaviour.

The rationale is that if you fully inherit a core (by providing just a variant/board) then it's perfectly fine to inherit all the "cores" libraries as well. This is no more true when you provide your own core.

For the same reason the IDE doesn't allow to "extend" or "partially replace a piece" of a core, for example by providing a single file like USBCore.cpp: in this case you're on your own and you must copy the whole core.

[NicoHood]

Cant we make those libraries more general as the Keyboard and Mouse library for example which work for both avr and arm? Cant we make avr only, arm only, both libraries that can be globally used?

Since they also appear on the boards manager (i think) they should be useable with different cores, if the core is made for AVR.

I dont need this feature anymore for my project, but I think libraries should be atmic and not connected with the core.

[cmaglie]

Unfortunately no.

The SPI library is strongly tied to a specific CPU, if you look at the source code you'll see that it makes massive use of registers and atomicity constructs specific for AVRs.
If you try to port the library to another CPU family you'll end up rewriting 95% of the library (basically, you'll keep only the class definition, look at the SAM or SAMD implementation to get an idea).

Moreover, every 3rd party core out there (avr, sam/d, stm, teensy, pic32, energia, etc.) have his own implementation of the SPI library, trying to converge them into a unique library it's like mission impossible and can easily become a maintenance nightmare.

For the record: I've (ingenuously?) tried to approach this path in the past but I've failed and I had reverted to the current way, that may allow the various implementations/API to diverge but has the advantage to let developers to maintain their own source code independently.

The same rationale applies for other CPU-specific libraries, like Wire for example.

[NicoHood]

Well then you should mark this as wontfix