The core code includes file(s) from libraries. That's backwards.

[majenkotech]

The core #include's (in at least one place) files from libraries. That's backwards.

If the core needs functionality that is shared with a library then the core should have the functionality and the library should call on the core's functionality NOT THE OTHER WAY AROUND.

One example:

• https://github.com/esp8266/Arduino/blob/master/cores/esp8266/uart.cpp#L45

As the core stands right now it cannot work in any other IDE that happens to have the libraries installed in a different location that the Arduino IDE installs them. It's just plain broken.

Any functionality that is in a library that the core relies on MUST be moved out of the library and into the core!

[TD-er]

Correct me if I'm wrong, but what is being installed when installing "esp8266/Arduino" is the entire tree as being presented here in this repo, right?
They only have other existing libraries included here in a way that makes it easy to upgrade one if needed.
So you're not installing the said library yourself, but it is a required one with a specific version, when installing "esp8266/Arduino". They are also installed along when installing "esp8266/Arduino" library.

[majenkotech]

I will correct you, since you are wrong.

If you use the Arduino IDE then things get installed correctly. If you do not use the Arduino IDE then you are at the mercy of the what the IDE in question works to put things in the right places.

That's not going to happen.

The simple fact is that you have the hierarchy of code inheritance the wrong way around.

Libraries use code that is in the core.
The core NEVER uses code that is in a library.

For example: UECIDE does not place the GDBStub library in ../../libraries/GDBStub. It places it in ../../../libraries/Misc/esp8266/GDBStub - And then only if the user has chosen to install that library.

You make assumptions based on one inferior IDE that do not hold true for other IDEs.

As it is I have to fudge the building of packages copying extra files from the library into the core and using sed to change the include path. And all because you have things blatantly backwards.

[TD-er]

Just one remark... I'm not the "you" here.
I'm also just a user of this core library for my project.

[majenkotech]

Fair enough. "You" refers to @earlephilhower in this case - according to the Github "blame" functionality.

[bxparks]

@majenkotech: You may be raising a good point, but why you are bludgeoning people who don't owe you anything?

[majenkotech]

The ESP8266 core is one of the most frustrating ones I have ever had the misfortune to port to UECIDE. Every version there is something silly that has broken and I need to spend hours rebuilding the whole packaging process and changing silly things in the control files. I never have such problems with other cores. For example, suddenly today I find that many of the option menus have changed their names for no apparent reason (true, I'm a number of versions behind, so that change probably happened a while back).

I spent a couple of hours today fixing all the things that seem to have randomly changed for no good reason, only to be faced now with this mess of a design choice. It seems sometimes like there's no quality control at all, and there's a pervasive attitude of "Meh, it works for me, that'll do" - with no thought given to anything outside the small blinkered environment of the Arduino IDE (which is, it has to be said, a complete joke.)

[bxparks]

All the devs here are volunteers as far as I'm aware, no one gets paid anything, you probably didn't pay them either. Your temper tantrum is not helping. ("small blinkered environment of the Arduino IDE"? The vast majority of people are on that IDE, whereas UECIDE doesn't even have a wikipedia page.) I suggest that sugar may be more productive than your vinegar..

[majenkotech]

I know all the devs are volunteers. I too am a volunteer. But if someone tried to commit such a change to the chipKIT PIC32 core they would just get laughed down immediately - volunteer or no.

[majenkotech]

And seriously, the Arudino IDE is laughed at by real embedded developers. It's a toy used by children. It's only "popular" because there's a lot of children (of all ages) getting into Arduino.

[TD-er]

Well, I don't use ArduinoIDE myself.
I use PlatformIO and that one also does a good job managing libraries.

[majenkotech]

None of this changes the fact that the core breaks the simple hierarchy of

Hardware
    V
API
    V
Libraries
    V
Sketch

and urgently needs fixing. Any layer of the hierarchy can access things in the same layer or a higher layer, but never a lower layer. Simple premise of API engineering.

[devyte]

Alright, enough.
@majenkotech strictly, you are correct. However, this clearly affects you, and nobody else since a long time. It therefore falls to you to find a fix and contribute it. Please prepare a PR to continue discussion there.

[majenkotech]

You know, this gets more and more bizarre. It seems there is no good reason to include the header from the library, since the core already contains a header that has the relevant prototypes in it. This is just odd.

Incidentally, here's another which could be harder to fix:

Updater.cpp:  #include "../../libraries/ESP8266WiFi/src/BearSSLHelpers.h"

In this instance Updater really should be broken out into a separate library so that it doesn't reside in the core. That way it is then allowed to access ESP8266WiFi.

---

That one is a complete tangled mess. The whole of the BearSSL and Updater system need refactoring to separate them out. I'm sorry, but I'm not touching that one. Maybe BearSSL (or portions of it) should be moved into the core instead of being in the WiFi library.