just to let you know.
If you try to compile the latest git version of ESPEasy against the latest core (post 2.4.0rc2) there is a compile error where it cannot find the min() and max() functions.
The issue is known https://github.com/esp8266/Arduino/issues/398 , however it seems to be closed.
Quickfix on our side:
insert the following two lines in libraries/IRremoteESP8266/IRremoteESP8266.h
Code: Select all
#define max(a,b) ((a)>(b)?(a):(b))
#define min(a,b) ((a)<(b)?(a):(b))There has been a nice and exhausting explanation on github by devyte:
In fact, he speaks the truth. After properly casting all min() / max() arguments the errors are gone. I filed an issue on github requesting an update of the offending library. But for now I stick to the define as it is just quickerTo everyone encountering build issues in 3rd party libs due to min|max:
The implementation of the Arduino core in this repo has migrated to conform to the C++ standard of min|max usage. The C++ standard min/max are not #defines, but templated functions that force the user to pass in both arguments of the same type. This is on purpose, and differs from the old-style #defined min|max implementation that is common in Arduino, where you can pass any pod type in.
The C++ standard decided on same-type args, because the #defined way made for implicit bugs, user errors, and build warnings with the usage.
For those 3rd party libs that have issues building, the reason is precisely that at some points in their code there are arguments of different types being passed in, e.g.: min(a,b) where a is int and b is uint16.
The 3rd party authors need to fix all such cases. In most, it is enough to cast one of the arguments being passed in to the type of the other, e.g.: min(a,(uint16)b). They will have to think about which way to case, and that is a good thing.
In other cases, they'll realize there is actually a bug in their usage, or even redundant code, and will need to fix it. That is also a good thing.
The above means that this is not a bug in this repo, but a fix in this repo that is exposing potential bugs in those libs, because our code is now stricter. Thanks to the C++ way, those exposed bugs are now caught at compile time instead of at run time, which is always desirable.
I suggest opening issues in the repos of those 3rd party libs requesting fixes. In the meantime, you can apply a workaround like the one described above if you really need it, but I advise against it.
I consider this resolved, so closing.
