Go Down

Topic: [arduino 1.5] "Not a valid library" importing Bitlash (Read 5 times) previous topic - next topic

Massimo Banzi


The whole purpose of having a separate IDE for a while is to work with the community to estailish standards to use in the future.
Adding a new core to the IDE to support a completely different processor is going to bring pain, we have done some preparatory work to be able to do that, the work is clearly not complete.

I don't exactly understand when you say "to have one's work broken without warning, again and again."
In 2010 we had a meeting with a number of prominent members of the community, we even flew a few of them from japan and europe to NYC to discuss the future Arduino 1.0, we blogged about it and we discussed it on the developer mailing list.
We mentioned over and over that we were going to break a few things in order to have an 1.0 API that could stay stable for a long time.
We released beta IDE's for a while and yet when 1.0 came out a lot of people acted like they were taken by surprise.

Now we're bringing to the table a completely new processor with many more possibilities, adding these features to the core is going require that we make some additions to the API keeping the old API stable as much as possible (for example pinMode on ARM should have many more modes, but the old one will still behave as expected.)

We've released the 1.5 IDE as beta, there are bugs, this is obvious. the Examples vs examples is clearly a bug that has been fixed already.

Having said this it's not a bad idea to have a discussion on how to clean up the directory structure of libreries to make them more standard.
At the end of this process we can write a nice wiki page with all the detailed specs and everybody will have the right info to work from.

Change happens , let's work together to drive where this is going. The beta of 1.5 is a chance for arduino to move to a more open development model

PS:where would be the right place to keep in touch with library writer? as it seems that our current channels do not reach all of them.


Massimo, I have the highest respect for your judgement and this platform.  It's your ecosystem.  You can break it if you want to.  

But hear me out.  As a long-time Arduino library developer, I can tell you it's both frustrating and disheartening to have one's work broken without warning, again and again.

Massimo: You won.  This platform is a huge accomplishment.  There are existing projects on Duemilanove boards that will be in operation for decades, perhaps long after we are dead.  This is goodness.  But unless the Arduino team perceives it to be part of its mission to provide a tool chain that will be compatible over that kind of time scale, those systems will become useless the first time a bug is found and an old library needs to be recompiled to fix it.

I would agree library developers have a responsibility to track the core.  But it is a fact of life that there are libraries that are not going to be maintained any more and therefore need to be buildable in their present state.

The thing that is particularly egregious about this proposed change is that it not only breaks current libraries, but it also prevents co-existence of future versions with earlier versions of Arduino needed to build older projects.

From my perspective, the team should take more seriously the impact of its decisions to break backwards compatibility.  If there is a way to keep the old libraries working, then keep them working, even if it's ugly compared to the shiny new stuff.  In my view, this is a responsibility that comes with the success of this project.

If the core team does not agree with this view, it would be helpful to hear.

Thank you for listening.  I'd be happy to follow up either here or privately.

Best regards,




Thanks very much for your reply.  I invite you to stop by next time you are in Denver to hear about Arduino development from this library developer's point of view.  Maybe we can get Nate to pay for the beer and sell tickets.

You don't address my point about breaking backwards compatibility and creating maintenance headaches for your best customers who have a lot of old projects to maintain.

It's really about who you are as a business and an institution.  Do you agree or not with this statement: "If it's possible to keep existing Arduino projects building in the IDE, it should be done!"

If the core team accepts that as a requirement, the conversation is over and we can all go back to coding.

In my opinion, if the core team doesn't accept that as a requirement, it changes the whole value proposition of the Arduino ecosystem.  How do I pitch Arduino when it's reasonable to ask whether the tool chain, including the third party libraries we all use, will still support the project when it's in maintenance a couple years down the road?

Long term support is an evolving thing in open source.  Massimo, I'm asking you and your company to help me help our shared users to have a better experience in the long run with this platform by avoiding this obvious and preventable mistake.  Please listen.



Oct 24, 2012, 05:01 pm Last Edit: Oct 24, 2012, 05:08 pm by retrolefty Reason: 1
So I have a question that this topic has seemed to have brought up. Not that I have or may ever release a 3rd party contributed library, but if I was and only developed it and tested in on AVR boards, would I be obligated to write it such that it could handle the new ARM based Due board? Would just having comments in the start of the .h file telling which processor(s) it was designed to run under be enough. What would be the proper etiquette for 3rd party library developers to use when releasing new library submissions in the future when it comes to what boards the code can support?

Again I'm more a hardware guy then software guy, but ever sense the announcement of the Due board I've felt that if would be best not to try and support both AVR and ARM based boards in the same IDE, but rather have separate IDEs that don't try or have to be 'compatible' with each other, they could certainly have the same look and feel, but be totally separate platforms. I just think there is a real possibility of taking on more then can be delivered and end up losing the simple to learn and use IDE that has been so useful for newcomers to the platform?



The new IDE 1.5 has 'fat' libraries support: libraries that contains code to run on more than one microcontroller architecture. The advantages of having a 'fat' library are clear:
- The IDE will automatically lists the available libraries based on the architecture of the currently selected board
- The same library can have multiple architecture inside => you don't have to install a different version of the same library for every architecture.

We also tried to introduce an auto-detection mechanism that takes apart non-fat libraries from fat libraries.
This mechanism didn't worked as expected because we assumed that library writers would only use 'examples' and 'utility' folder. This is a clearly wrong assumption, and the patch i have just pushed on the repository fixes this problem.

So, guys, don't worry: all your libraries will continue to work as expected (of course if you try an AVR specific library on the Due it will not work).

I'll invite you all to check if the patch will fix the issues you are having.



Thanks, C.  Tested and working here for Bitlash and the other libraries I had problems with.

For others who may want to test, here's what it takes to fire up the build with these changes (OS X, Xcode tools installed):

Code: [Select]

> git clone https://github.com/arduino/Arduino.git
> cd Arduino
> git fetch origin ide-1.5.x
> git checkout ide-1.5.x
> cd build
> ant
> ant run

I love the sound of "libraries will continue to work as expected."  Thanks.

Now to go chase some compiler errors on the Due side...

Question for C: is there an official #define that distinguishes the Due/Arm build from the AVR builds?


Go Up