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.

[devyte]

Feel free to add that fix to #6390, or you could also make a separate PR.

[d-a-v]

I'll take only one example to illustrate your clumsy way to expose your frustration.

For example, suddenly today I find that many of the option menus have changed their names [...]

It suddenly appeared a year ago

#5100 (comment)

It is also mentioned on top of https://github.com/esp8266/Arduino/releases/tag/2.5.0

and addressing an Arduino IDE issue on windows, that is fixed since then. That fix wasn't for maintainers since (afaik) we don't use windows ("Meh, it works for me, that'll do" doesn't hold). And yes we are aware that it is a breaking change, as mentioned, and as we were loudly told.

But bugs have to be fixed right ?

[...] for no apparent reason

You are aware of the github "blame" functionality though, if I read your comments well.

We, not speaking only for maintainers, are willing to make the best of our tiny blinkered toy.
You are free to not use it.
You are allowed, as we all are, to come and improve it for the best.
Your precious time will be valuable for any professional improvement.

[majenkotech]

We, not speaking only for maintainers, are willing to make the best of our tiny blinkered toy.
You are free to not use it.
You are allowed, as we all are, to come and improve it for the best.
Your precious time will be valuable for any professional improvement.

I have. I've spent the past 6 years doing just that. It's called UECIDE. I took the Arduino IDE and turned it into a useful tool. Much of what is in the Arduino IDE now functionality-wise was inspired by my work in UECIDE. Things like the boards manager and the ability to have more than just AVR. Things like library management. Those concepts all existed within UECIDE long before the Arduino IDE. But the Arduino IDE is still fundamentally lacking in almost every area that would qualify it as a real IDE, and not a toy.

The only time I ever load the Arduino IDE is to confirm the existence of a bug when a "user" is having problems with it. Things like the AVR-GCC windows compiler segmentation violation bug. Things like the repeated problems people have had downloading the ESP8266 core (the IDE thinking the downloaded file is corrupt for some reason).

[me-no-dev]

What is that UECIDE that you are ranting about so much? Never ever heard of it and it exists for 6 years? Either I am living under a rock or it is not as marvellous as you try to explain. You can call Arduino IDE whatever you want, but reality is that it is used by millions and is their way to enter embedded programming (like I myself did some time ago). Stop ranting and either provide a fix or use something else. You know for such awesome developers like you, there are FreeRTOS and NonOS official SDKs from Espressif, right? They are for professionals. Anyway... how many platforms did you port to Arduino? Any?

[majenkotech]

You must be living under a rock.

Let's see... I'm lead programmer and hardware designer for chipKIT™ - the Arduino core for the Micripchip PIC32 family of microcontrollers (pre-dates the esp8266 core by a number of years - your core is a newcomer by comparison). I have created (though not released to the Arduino IDE) cores for the PIC16/PIC18 (not released because there isn't a free C++ compiler, so it uses a number of ungainly fudges to approximate the API). Not to mention being a major contributor to embedded operating systems such as RetroBSD and LiteBSD.

[dok-net]

@d-a-v @devyte What about this? You know, I'm into refactoring from core to libraries, so this was a no-brainer - which means, it may be completely broken just as well smiles

PR #6393

Please help me fill in the library.properties correctly, if this even makes any sense to you.

[d-a-v]

for the PIC16/PIC18 (not released because there isn't a free C++ compiler, so it uses a number of ungainly fudges to approximate the API)

aah that's too bad :( because we can indeed compile c++ with free tools for these chips, with LLVM and C backend. I'd have loved to have arduino for the 18f43k22.

You must be living under a rock.

... maybe we are not professional enough.

Your high level professional experience and skills over wide spread and very well known projects would be helpful to help fixing this core.

[dok-net]

New attempt, as suggested by @earlephilhower: no new library, but if signing is requested in build process, Updater.cpp exposes two stubs that are filled by implementations in ESP8266WiFi's BearSSLHelpers (or anyone else for that matter).
PR #6398.

[earlephilhower]

#6398 has been merged, so I think the original issue is taken care of. Closing, but if there's something else do re-open or make a new one to track.