-
-
Notifications
You must be signed in to change notification settings - Fork 7k
request to add NeoPixelBus library #4484
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi, your library is without a tag, so at the moment it can't be added to the library manager. Please follow this guide: |
So is the suggestion that expose releases targeted from branches tagged with specific platforms then? "v1.0" - all platforms but has esp8266 support that has issues due to esp SDK changes ? |
the rule is: everything you tag is going to be published in the library manager and it will appear with the name and version written in the file Currently I see no tags in your library: https://github.com/Makuna/NeoPixelBus/releases so as it is now cannot be published.
that would not work because the IDE will consider all those tags as versions of the same library, and the IDE will ask the user to always upgrade to "1.0". The best solution IMHO would be to have a single library that works in the three cases. I don't know the details but wouldn't thibs be accomplished by using #ifdef with platform values? |
AVR doesn't include basic STL functionality while some platforms do. New features in C++ can't be used easily without them (see functional). The latest designs rely on this to make it easier on the consumer to use these new features. I have yet to find a STL library that works and includes "functional" for the AVR platform. Let alone then we have the nightmare of dependent libraries of which you have no solution yet. Fix this, and I am halfway there. Further, how does a user set one of these #define that works within a library, as one platform has two versions (esp has uart and dma, due to dma pins not exposed on some modules and the uart pins is valuable to loose for those that do expose the pins). The only way I have had it work is by modifying the library header file (not a nice thing to require novice users to do and a nightmare to explain and have them manage if they work between two versions, and I do have customers that use both the esp versions). Again, if Arduino IDE exposed per sketch way of seeing and adding defines that gets applied across all files being compiled then I would have a workable solution. Today those customers use GIT client to select the branch and it just magically switches for them (easy to explain, quick to happen) but still annoying to customers of the library. I could create two completely different repos, but this creates a maintenance nightmare for me as there is a lot of shared code between the versions. So, its not so simple. And I am stuck not being able to expose my library in your system due to a bunch of limitations out of my control. |
That would be my suggestion, as it sounds like you actually have three separate libraries. You can try using Git submodules for the shared code between the repos. |
@sandeepmistry It truly DOES NOT SOUND like I have separate libraries to me. While I appreciate your feedback, I do not agree with it. I do want to merge into one code base, but the Arduino IDE limits me in doing so (lack of per sketch define, lack of modern STL library support built in). Truly, I would rather not support the library manager feature than require that I have three repos to do so. Feedback from my customers so far has been ignore the library manager and just use the GIT client to switch, they all think its faster and easier anyway. Many are switching to PlatformIO due to many reasons so most don't care about library manager anyhow. I don't like using Git client solution, but Arduino IDE has in the past left me without an option and is continuing to provide a solution that doesn't help me. |
When I build with the esp core for Arduino (using http://arduino.esp8266.com/stable/package_esp8266com_index.json) I see that the following compile time variables are automatically defined:
this is the command line used for the build by the IDE (output obtained in verbose mode):
@Makuna
take a look at this one: https://github.com/kibergus/StandardCplusplus |
But for other Esp, the user needs to be able to select between DMA and UART, based on which pins they have available in their designs. This doesn't solve that problem. Thanks for the pointer to that library, I will look into it. |
Ok, tried the reference library. Its a version of STL that is basically OLD! Its hard for me to tell exactly how old as it looks like bits have been merged in over time, but the functional is not very easy to use due to using older harder to use templates. The whole reason I use the newer version with my library is to make it easier on the consumer and the referenced one is missing these. I really wish the Arduino AVR environment would just include it. Its not really a library as much as part of the environment. It was real nice that the C++ compiler got moved up to a modern version, but the newer STL makes it a lot easier to consume those new features exposed by the new standards. |
Ok, I ported an STL myself, and it looks like the Arduino precompiler for INO doesn't understand function templates correctly and errors on them and this stops my advanced library being used for AVR.
that for AVR builds returns the error "error: 'function' does not name a type". |
UPDATE: After a complete architecture change, I now have one library and a release was published. So this is ready to be reviewed and closed. |
Done thank you! |
How long does this take? Its been two full days and it still isn't showing up in the LibraryManager. My other Libraries it happened overnight. |
https://github.com/Makuna/NeoPixelBus
I want to include specific branches.
The master branch is generic but old and I really don't want to include it.
The NeoPixelAnimator branch is generic and I would like to include it but it does not support the esp8266 well.
The DmaDriven branch is esp8266 specific and this currently supports the new library format and the one I wish to include.
The text was updated successfully, but these errors were encountered: