.. (and probably jantje would kill me ,..
Bill!First I want to reassure you that if you want to stick to the 1.0 lib format, you can safely do that, we are not going to remove old library support. We already discussed that (in a google issue maybe? I can't remember), so I don't know why you're so concerned about that yet.Because of history and because of various comments like what you just said:Quotewhy you're so concerned about that yet.Eventually "yet" arrives, and from my perspective, it was poorly handledon the 1.0 release.When 1.0 was released,several things were changed at the last minute that brokebackward compatibility with existing libraries.100% of the 3rd party library code that was stable for MANY years and was workingon all the beta releases of 1.0 was suddenly made obsolete and no longer compiledon the final 1.0 release.The Arduino team deliberately made the decision to break 100% of the existing 3rd party library codeto force everyone to update their libraries. There were easy ways to make most of the existing codecontinue to work, but the Arduino team decided against it.This is an example of a decision that didn't impact the library code included in the Arduino release but had a dramatic impact on all the 3rd party codeand developers.We are still fighting issues related to this.This why I have such concerns.You're right about the fact that the library properties doesn't manage specific chips inside an architecture, we deliberately made this decision, otherwise we would end up with a structure like arch/[architecture]/[cpu] (and probably jantje would kill me , for example arch/avr/atmega328: this lead to massive code duplication since code for atmega328 is very similar to code for many other atmegaxxx, sometimes only a single line of code or a register name is different, and that can be handled easily with #ifdefs.The same is not true when you move your focus from CPU to ARCHITECTURES: different architectures like SAM and AVR have very low code matching, practically null, and you end up using #ifdefs to select the whole file: in this case is much more clear and handy to use different files at all.It isn't quite that clean and simple.What happens when you have multiple vendor cores that support the same CPU Architecture?The current .properties library spec doesn't seem to handle this.i.e. think, maniacbug1284p, attiny, TeensyAll those are "AVR" but yet are different vendor/maintainer cores.I also think that it should not be assumed that code differences are primarily due to low level hardware differences.There are cases where the differences are due to the toolset related to an architectureand are a s/w only compatibility matter.In those cases you can have a similar situation as to what you mentioned above, usingan ifdef around minor code differences.For example, there can be slight differences as to how AVR vs ARM vs pic32 handletheir standard i/o which can affect a library. tool/board/architecture/chip portability mapping is never an easy thing to resolveand people will always have differing opinions about what methodology works better.My concern is that not enough thought has gone into the new library design to make it really usefulin 3rd party environments.I'm concerned that the 3rd party guys may end up with a system that is different but still doesn'tsolve many of their needs.To a large extent I think this effect is quite natural in that the Arduino team is focusedon their release - as they should be - so there isn't really a focuson how to help out the 3rd party developers, which might even be competitors.I do believe that In some cases there may be situations where a given methodology maywork better for the 3rd parties but have no benefit to the official Arduino code.If that methodology creates more work for the Arduino team, it may be adifficult hurdle for the 3rd party community to convince the Arduinoteam to pursue that path.I brought some of this up earlier but here is some additional detaila few items that seem problematic.For example, how do other cores really fit into this?i.e. what about other cores that are in use like maniacbug1284p, or attiny?Both of those are AVR architectures, but the current .properties spec doesn't appear to have away to deal with this.The 1.5 hardware spec clearly shows how different vendors create their own subdirectory andthen can create architectures below. But in the .properties spec, there is no reference to thesecore "vendors"/maintainersAlso the related 1.5 hardware spec doesn't go into details on where the vendor should put his toolsfor his architectures.Currently, the "Arduino" vendor that ships with the IDE,puts it's build tools in the "tools" directory parallel to the "vendor/maintainer" directory.Having integrated the chipKIT cores and tools into an early 1.5 environment,I found it worked better to put the build tools under the actual architecture directory to keep everything together.For chipKIT there were also issues that required this given that some of the tools overlapped butwere actually different.Having the all the build tools under the architecture directory allowed the chipKIT support to beadded into Arduino 1.5 by simply copying over a single directory.And BTW, when the chipKIT support was integrated, chipKIT boards were using arduino 0023 vs Arduino cores using arduino 1.5all under the same 1.5 IDE.This is an example of how cores can get skewed and a reason to consider this.I believe it is naive to believe or require that all the architecture cores must remain in full sync with the IDE.There needs to be a decoupling of the IDE from the tools and and the cores. May we could extend just the .properties file to say that a library runs only on a specific chip? so for example a library for a 32u4 would not be listed when the selected board doesn't have a 32u4? Maybe. If this approach moves forward, then I think that the .properties should support manyof the properties from the board.txt file.That way a library or sketch (assuming there is an optional .properties for sketches) could specify anythingit wants as a dependencyWe could extend that also to the examples? Maybe.I would like to see a proposal from you on how you will do that.These are all things that can be added (also later) to extend the capabilities of the library specification. BTW, this is all parsing work that will go to the back of tools-maintainers too.It depends. For example, if much of this property stuff is just to create pretty/clean lists oflibraries or examples in the IDE GUI for the user, then no, the 3rd party tools may not have to support this sincethey may have different way of specifying libraries.It would be nice to have a system that could benefit the Arduino IDE but doesn't unduly burden the 3rd partytools that didn't need the capability."dependency" and "dependency-core" are placeholders for the future library manager. The version specified in the dependency-core is the version of the CORE (and not the IDE as you presumed, even if they are still coupled). You can find the core version inside the platform.txt file. As you can see those fields are just drafted and there is room for improvements here when the library manager will be put in place. I'll make an announcement on the developers list when we start to define it.At the moment the IDE doesn't enforce dependency check on those fields. I'm happy to see how you would improve that, consider that they are mainly focused for machine-dependency check on the future library manager.But what does "CORE" really mean?What happens when you have other 3rd party cores? It doesn't appear that it is possible to specify that a library only works on that core?i.e. suppose the library wants to specify that it only works on Teensy or maniacbug1284p cores?
why you're so concerned about that yet.
About compatibility of 1.5 library with IDE 1.0: its true, but again, how would you change the specification to allow that? See that there is very small room for improvements on the old lib-1.0 format.
Guys,Since you're requesting it, let's go talking about the library specification on the developers mailing list.To let everyone subscribe on the developers list I'll start a new thread about that in a day or two.Here the link to subscribe:https://groups.google.com/a/arduino.cc/forum/#!forum/developers
First I want to reassure you that if you want to stick to the 1.0 lib format, you can safely do that, we are not going to remove old library support. We already discussed that (in a google issue maybe? I can't remember), so I don't know why you're so concerned about that yet.
At some point in the future, the IDE will drop pre-1.5 library support. There is no specific timeline for this, it will be determined once the new library format has become widespread.
I do have a bit of an off topic question:Why use Google Groups? Why not have the discussion over here on the Arduino Forum?
Actually, I didn't know there was a developer site for Arduino on Google, as the code is hosted at GitHub and the forum is here. Quite confusing!
Maybe the goals & purpose of this library spec aren't clear?Bill's been talking a lot about whether the IDE offers incompatible libraries and examples. But I can't find any mention of that actually being an intended goal. If the metadata is going to be used to filter what libraries, examples and other options are offered to users, I can't find anything written about how that's supposed to work.The spec does talk about 2 goals: #1: facilitating a library manager that automatically downloads libraries from a central server, and #2: supporting multiple architectures.
When the user chooses a board the IDE automatically selects the correct library implementation for the board's architecture. If a library doesn't provide an implementation for the currently selected architecture, the library is not displayed cannot be selected. Examples are shown only if the library has an implementation for the currently selected board architecture.
Also note the with the library.properties you can filter the library from being displayed/compiled on architectures that are not supported by the library itself.
Regarding multi-arch support, I must agree with Bill, requiring a directory structure that isn't compatible with 1.0.X is obviously going to lead to very slow adoption of this spec. As the author of several libraries and the current maintainer of several more, it's pretty easy to choose between publishing in a format that works on all widely used Arduino IDEs, versus a format that only works on the newest.
Cristian, I'm really glad you said this:QuoteFirst I want to reassure you that if you want to stick to the 1.0 lib format, you can safely do that, we are not going to remove old library support. We already discussed that (in a google issue maybe? I can't remember), so I don't know why you're so concerned about that yet.I'd like to point out some language near the end of the spec, which might be the source of concern:QuoteAt some point in the future, the IDE will drop pre-1.5 library support. There is no specific timeline for this, it will be determined once the new library format has become widespread.Maybe this part of the spec should be updated, if you're really committed to keeping the old format supported?
For example, if we try to compile the above library for a board based on AVR architecture, the IDE will automatically compile and include the following folders:
Be kind to the end user. Match your API to the underlying capabilities. You don't want to expose implementation details to the userOrganize your public functions around the data and functionality that the user wants. Use full, everyday words.
billI guess you are asking the wrong person on how it is currently implemented.What I was trying to solicit is to see is if everybody else is seeing the flawsin the current .properties specification with respect to trying to specify 3rd party coresor architectures within those 3rd party cores.The only more or less 1.5 compatible teensy right now has been build by me. (off course with help of Paul)As far as I remember (I don't use the ide) it works in the IDE for Teensy2 and Teensy2++ but surely not for Teensy3.It is still setup in the pre 1.5.3 format (that is without the library specification we are discussing here) so all libraries are under hardware/teensy. Also all executable code is there. So I used teensy as vendor. (pretty obvious)I did similar for chipKIT a year ago.I have a working chipKIT environment that works with the Arduino 1.5.1 IDE GUI.It wasn't that big of deal since the libraries were all separate at that time.This allowed chipKIT to be using 0023 while the avr and sam used 1.5.1Paul preferred (like I do) to only have 1 "hardware folder" so I named it all. So in my implementation teensy hardware is called all.In the oo spirit (I also elaborated about in my previous post) my plugin allows boards.txt to overwrite all!!!!!!! settings in platform.txt.This allows me to overwrite even the compiler command. Which is needed for Teensy3.However Teensy3 does not make a library so I had to add a special flag which is not supported by the arduino IDE.I didn't follow that.You can do pretty much anything to the compiler, linker, and download commands given theflexibility offered by the platform and board files. I had to completely change things for chipKIT but the flexibility wasthere for me to change all the commands around when chipKIT boards were selected withouthaving to change anything in the Arduino JAVA IDE code.On the hardware/[arch] folderI never really understood the need for an [architecture] folder. I mean When a artist buys a due because he has been told he needs that board. Does he care it is sam or avr when he doesn't even know what that means? (I don't know what sam and avr means) While agree that end users should have not to know too much low level details,I didn't follow the rest of your comment about "architectures"At a minimum, there as to be separate areas for the different toolsets given multiple toolsetsare required to develop across the different processors.As far as the end user goes, most of what are discussing is completely hidden fromthe normal end user.The user doesn't have to know any of this as long the system allows a libraryto specify which environments it works in.But to do that the library writer and core developer has be very familiar with thesedifferences and how to configure and specify what works togetherAND the system must be capable of allowing enough information to be specifiedto ensure that the system can select the proper tools and libraries once the userspecifies which board he is using.In the bigger picture, 3rd party Core, Library, and tool writers are not normal users.They are the ones that create the s/w to make it easy for the normal users.What I'm trying to bring up is that from a purely functional point of view(ignore how ugly or painful it might be to actually implement), the current.properties spec does provide enough information to specify whichcores and sub architectures within a core are supported by the library when3rd party cores are involved or when a library is specific to a particular chip.And without those types of capabilities,it is impossible to provide a nice clean & simple user experience.I also believe that it is more important to resolve the functional issuesbefore the implementation issues.