You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to prevent conflicts and path problems with pre-existing libraries, may I suggest M5Stack is bundled with a variable that contains its own version?
Currently, if I have a M5 project using qrcode.h, it works fine with 0.1.6 but breaks with 0.1.7.
This is because M5 suddenly decided to embed a library that is not made for embedding.
Since there's no way to detect from the .ino sketch what version of M5Stack lib has been loaded in the Arduino IDE, doing so with 0.1.7 causes duplicate declarations errors,
This creates a situation where every M5 project using one of the new libs will break, or will have to maintain two codebases until the M5Stack 0.1.7 lands in the ESP32 environment.
In order to prevent such a SNAFU, M5 library should take care of the problem it created by giving the possibility to the developer or the compiler to avoid the breaking situation.
Suggested solution: "tattoo" all upcoming versions (including 0.1.7)
This could be done every time a new release is produced:
Hello,
In order to prevent conflicts and path problems with pre-existing libraries, may I suggest M5Stack is bundled with a variable that contains its own version?
Currently, if I have a M5 project using qrcode.h, it works fine with 0.1.6 but breaks with 0.1.7.
This is because M5 suddenly decided to embed a library that is not made for embedding.
Since there's no way to detect from the .ino sketch what version of M5Stack lib has been loaded in the Arduino IDE, doing so with 0.1.7 causes duplicate declarations errors,
This creates a situation where every M5 project using one of the new libs will break, or will have to maintain two codebases until the M5Stack 0.1.7 lands in the ESP32 environment.
In order to prevent such a SNAFU, M5 library should take care of the problem it created by giving the possibility to the developer or the compiler to avoid the breaking situation.
Suggested solution: "tattoo" all upcoming versions (including 0.1.7)
This could be done every time a new release is produced:
echo "#define M5_LIB_VERSION F(\"$(git describe --tags --always --dirty)\")" > gitTagVersion.h
and of course including it from somewhere in the stack:
#include <gitTagVersion.h>
so we can easily use something like this:
and not being forced to maintain our project code every time M5 maintains its code :-)
The text was updated successfully, but these errors were encountered: