Comments on Arduino 1.5 Specifications

[Jantje]

I would like to propose a solution which I think is acceptable for Arduino core team and all tool developers.

In the .cpp and .c files in the library folder
add a #ifdef ARDUINO_ARCH_{build.arch} at the top and #endif at the bottom.
This would mean that all *.c *.cpp files in avr start with

Code: [Select]

#ifdef ARDUINO_ARCH_AVR
and end with

Code: [Select]

#endif

As ARDUINO_ARCH_{build.arch} is already defined in platform.txt this is the only thing needed.

I hope this is accepted by the core team
Best regards
Jantje

[avenue33]

@Jantje

Another option would consist on duplicating the libraries and copy them into a structure plain GNU GCC Tools can understand and manage.

[Jantje]

@ avenue33
I think this is a structure plain GNU GCC Tools understand.
What I plan to do is
1) use the libraries/[libName] folder as source code (excluding Example). This way all code is known by the tool.
2) only add libraries/[libName]/src to the include path

I tried this in eclipse and it works.
Why? (taking the servo lib as example)
The tool sees all the source files
-Libraries/Servo/avr/Servo.cpp
-Libraries/Servo/sam/Servo.cpp
Due to the define statement ARDUINO_ARCH_AVR in /Servo/sam/Servo.cpp the output file for /Servo/sam/Servo.cpp will not contain any compiled code.
The compile process of /Servo/avr/Servo.cpp on the other hand will generate  code.
So if your toolchain supports directory trees and filenames with the same name at different locations in the directory tree this solution should work for you.
IMHO all C/C++ tools support this.
There are some tricks of the trade that need to be used. For instance having twice a header file with the same name. In the Servo example that is ServoTimers.h
By not adding the lib[architecture] folders to the include path and using a include statement with double quotes the file in the folder of the source file will be used.

As stated this works with eclipse. Can you check with your environment?
Best regards
Jantje

[cmaglie]

It is with pain in the hart that I conclude that I currently see no other option than stopping my Arduino eclipse plugin purely for this library specification.

Believe me, this is the last thing that I want to see happen. So, first, thanks for your patience, I'm sure we can find a solution.

In the .cpp and .c files in the library folder
add a #ifdef ARDUINO_ARCH_{build.arch} at the top and #endif at the bottom.
This would mean that all *.c *.cpp files in avr start with

Code: [Select]

#ifdef ARDUINO_ARCH_AVR
and end with

Code: [Select]

#endif

well, this is what we are trying to avoid: repeating the same #ifdef when its not needed.

I know how I can modify the Arduino eclipse plugin so the makefile is ok. However this will not work for the indexer. As such the indexer will not know whether you are using sam or avr which reduces the added value of using a real IDE.

There are basically 2 options I still see possible.
The first is to add a lot of code to add and remove path variables when libraries get added or removed.

What your plugin does when a user adds a library?
I see that you already handle the variant folder: for the libraries it should be the same, or something very similar, what I'm missing?

[avenue33]

What your plugin does when a user adds a library?
I see that you already handle the variant folder: for the libraries it should be the same, or something very similar, what I'm missing?

The embedXcode plug-in imports all the libraries from the [font=Courier]Steckbook/libraries[/font] folder and indexes them. Same for the libraries for the application libraries from  [font=Courier]/Applications/Arduino.app/Contents/Resources/Java/libraries[/font], the variant libraries from [font=Courier]/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/variants[/font] and the core libraries from [font=Courier]/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/cores[/font].

When the user wants to use a specific library, he/she just adds the corresponding [font=Courier]#include[/font] statement.

Because embedXcode manages different paltforms --Arduino, Digispark, chipKIT, LaunchPad, Maple, Teensy, Wiring--, the same process is done with the other platforms for the core, variants and application libraries.

[Jantje]

It is with pain in the hart that I conclude that I currently see no other option than stopping my Arduino eclipse plugin purely for this library specification.

Believe me, this is the last thing that I want to see happen. So, first, thanks for your patience, I'm sure we can find a solution.

I'm happy to hear this.

In the .cpp and .c files in the library folder
add a #ifdef ARDUINO_ARCH_{build.arch} at the top and #endif at the bottom.
This would mean that all *.c *.cpp files in avr start with

Code: [Select]

#ifdef ARDUINO_ARCH_AVR
and end with

Code: [Select]

#endif

well, this is what we are trying to avoid: repeating the same #ifdef when its not needed.

I don't see why you use the word repeating. if each implementation has 1 header and 1 source file each #ifdef ARDUINO_ARCH_{build.arch} is only needed once (source code) and to be perfect twice (source code and header so the indexer does not see double declarations)
I do not see why you are trying to avoid this. Each and every header file should have something similar to handle multiple inclusions.
IMHO it is also good that you can see (and get guarantee) that this code is only used for a certain platform.

I know how I can modify the Arduino eclipse plugin so the makefile is ok. However this will not work for the indexer. As such the indexer will not know whether you are using sam or avr which reduces the added value of using a real IDE.

There are basically 2 options I still see possible.
The first is to add a lot of code to add and remove path variables when libraries get added or removed.

What your plugin does when a user adds a library?

When a library is added the plugin adds a symbolic link to the root of the library folder at the location [project]/libraries/[libraryname].
It also adds a include link for all languages (C and C++ in V2 and C C++ asm in V1).
The end user needs to add the include to the code himself.
Note I do not have a delete library functionality. A user can delete the link but that will not remove the includes.

I see that you already handle the variant folder: for the libraries it should be the same, or something very similar, what I'm missing?

You are right about the variant folder being similar but it is not the same.
Let me first explain how I handle the variant/core
I create 2 symbolic links one with the name [project]/arduino/core and one with [project]/arduino/variant. These link to the appropriate location on disk.
I also create 2 include links to /arduino/core and arduino/variant.
This means that when the user selects another board I may need to update the link location of the link names  /arduino/core and arduino/variant.
Note that this solution breaks the symmetry between the "disk situation" and the "eclipse project situation".
The main reason why this works is because arduino only uses

Code: [Select]

#include "pins_arduino.h"
In other words it relies on the include path to find the file.
When we have a mega; makefile will find it at arduino-1.5.2/hardware/arduino/avr/variants/mega/pins_arduino.h.
The indexer however will find it at [project]/arduino/variant/pins_arduino.h
Understanding this difference is important for the next part.

Suppose I do something similar for a library.
I create 2 link locations [project]/libraries/[libname]/lib/arch and [project]/libraries/[libname]/src.
[project]/libraries/[libname]/lib/arch links to ../libraries/[libname]/lib/[arch]
[project]/libraries/[libname]/arch links to ../libraries/[libname]/src
I add [project]/libraries/[libname]/lib/arch and [project]/libraries/[libname]/src. to the include path.
Apart from the maintenance nightmare (There is no delete lib and I don't know how to make one) and apart from the potential performance impact when changing board I expect this to work in all cases for the makefile but not for the indexer.

One scenario I think of is the following:
I'm building a board  that has a "different" architecture than avr but is very much alike. Some libraries need to change but some are 100% compatible. Suppose this architecture is called "jantje"
For each library I support I create the folder jantje under [libname]/lib/ where I place my code.
Assume that the Servo lib I need is 100% compatible with the avr lib. What I will do is create 2 files:
Servo.cpp which looks like this

Code: [Select]

#include ../avr/Servo.cpp
ServoTimers.h which looks like this

Code: [Select]

#include ../avr/ServoTimers.h
This will work fine for the makefile but not for the indexer as [project]/libraries/[libname]/avr does not exist.

I hope this explanation is understandable; it is clearly not as simple as embedXcode .
Best regards
Jantje

[Jantje]

avenue33
From your explanation it is not clear to me (and I guess the same for cmaglie) how you select the correct pins_arduino.h.
Can you elaborate on this?
Best regards
Jantje

[avenue33]

There are two different things:

• library indexing for code-sense, explained in my previous post


• library selection for build and link, explained below.

The [font=Courier]pins_arduino.h[/font] specific to the board selected --e.g. Arduino Leonardo-- is managed with the choice of the variants folder...

[font=Courier]/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/variants/leonardo[/font]

... through the [font=Courier]boards.txt[/font] file...

Code: [Select]

leonardo.build.variant=leonardo

embedXcode considers the sketch as a standard C++ program --actually, a library of main.cpp-- and doesn't perform under-the-hood hidden processes. Everything is managed by a makefile and the GNU GCC tools-chain.

The biggest obstacle for add-ons like Jante's for Eclipse or mine for Xcode lies on those under-the-hood hidden processes done by the Arduino IDE.

Or to put it with other words: the Arduino team should understand that Arduino is actually two things (from a software point of view)

• an easy-to-use but limited IDE


• and a framework, inspired by/similar to Wiring.

That framework should remain usable with any standard IDE like Eclipse, NetBeans, Visual Studio or Xcode, to name a few. Hence this very thread.

[pjrc]

I don't have much to add at the moment, but I'd like to let you know I'm following this discussion.

Sometime next year I'm planning to create a makefile + utility (a native command line program, compiled for all platforms) that more faithfully replicates Arduino's build process.

[avenue33]

I don't have much to add at the moment, but I'd like to let you know I'm following this discussion.

Sometime next year I'm planning to create a makefile + utility (a native command line program, compiled for all platforms) that more faithfully replicates Arduino's build process.

Paul, thank you for your support.

Actually, I'm not sure the Arduino way of compiling a sketch is the most adequate way with so many under-the-hood hidden processes...

The Arduino IDE is lacking a critical feature more powerful MCUs --and thus larger projects-- call for: debugging. Only Texas Instruments offers the Arduino-based Energia framework with the debugging tools from Eclipse-based Code Composer Studio 6.

So why not to focus your makefile + utility on a standard IDE-friendly project?

I know that "developing an Arduino sketch is not programming" but let's stop the fairy tales and face the reality: avoiding any reference to C++ makes portability and scalability very difficult to achieve, when the framework is strong enough for large project.

[cmaglie]

I don't see why you use the word repeating. if each implementation has 1 header and 1 source file each

this is not true, an implementation can have many files. Look at the TFT or Ethernet library:
https://github.com/arduino/Arduino/tree/ide-1.5.x/libraries/Ethernet
https://github.com/arduino/Arduino/tree/ide-1.5.x/libraries/TFT

Nonetheless there are some maintainers that actually keeps tens of libraries, the time that you save on the development of the tool is time that you put on the back of the library author. With the 1.5 library specification we are focusing to this audience, not the tools developers.

I do not see why you are trying to avoid this. Each and every header file should have something similar to handle multiple inclusions.
IMHO it is also good that you can see (and get guarantee) that this code is only used for a certain platform.

Because, there are a lot of project that uses the same approach, and they don't need these guards, because IMHO are useless. One for all (but you can find a lot more that adopt same structure):
https://github.com/mirrors/linux/tree/master/arch

Note: kernel uses the makefile and the GNU GCC tools-chain.

If you google "c++ multiplatform" there are a number of forum that suggests the current 1.5 library structure is the "best" way to go:
http://stackoverflow.com/a/3627208/1655275
http://stackoverflow.com/a/14592359/1655275
these are the first two that are relevant but there are many more.

When a library is added the plugin adds a symbolic link to the root of the library folder at the location [project]/libraries/[libraryname].
It also adds a include link for all languages (C and C++ in V2 and C C++ asm in V1).
The end user needs to add the include to the code himself.
Note I do not have a delete library functionality. A user can delete the link but that will not remove the includes.

Ok, so it links for example:
Project/libraries/Servo -> Arduino-1.0/libraries/Servo
Let's forget about the remove lib functionality for now.

You are right about the variant folder being similar but it is not the same.
Let me first explain how I handle the variant/core
I create 2 symbolic links one with the name [project]/arduino/core and one with [project]/arduino/variant. These link to the appropriate location on disk.
I also create 2 include links to /arduino/core and arduino/variant.
This means that when the user selects another board I may need to update the link location of the link names  /arduino/core and arduino/variant.

Link Project/arduino/core -> Arduino/hardware/arduino/avr/cores/arduino
Link Project/arduino/variant -> Arduino/hardware/arduino/avr/variant/leonardo (for example)
Add to build/include path: Project/arduino/core
Add to build/include path: Project/arduino/variant

Note that this solution breaks the symmetry between the "disk situation" and the "eclipse project situation".
The main reason why this works is because arduino only uses

Code: [Select]

#include "pins_arduino.h"
In other words it relies on the include path to find the file.
When we have a mega; makefile will find it at arduino-1.5.2/hardware/arduino/avr/variants/mega/pins_arduino.h.
The indexer however will find it at [project]/arduino/variant/pins_arduino.h
Understanding this difference is important for the next part.

That's perfectly clear for me until now, it reproduce exactly what Arduino IDE does.

Suppose I do something similar for a library.
I create 2 link locations [project]/libraries/[libname]/lib/arch and [project]/libraries/[libname]/src.
[project]/libraries/[libname]/lib/arch links to ../libraries/[libname]/lib/[arch]
[project]/libraries/[libname]/arch links to ../libraries/[libname]/src
I add [project]/libraries/[libname]/lib/arch and [project]/libraries/[libname]/src. to the include path.
Apart from the maintenance nightmare (There is no delete lib and I don't know how to make one) and apart from the potential performance impact when changing board I expect this to work in all cases for the makefile but not for the indexer.

this is less clear to me, just to clarify, you are saying (supposing a Leonardo board is selected):

Link Project/libraries/Servo/lib/arch -> Arduino-1.5/libraries/Servo/lib/avr
Link Project/libraries/Servo/arch -> Arduino-1.5/libraries/Servo/src
Add to build/include path: Project/libraries/Servo/lib/arch
Add to build/include path: Project/libraries/Servo/arch

but I guess you typo the first link probably you meant:

Link Project/libraries/Servo/lib/arch -> Arduino-1.5/libraries/Servo/arch/avr
Link Project/libraries/Servo/arch -> Arduino-1.5/libraries/Servo/src
Add to build/include path: Project/libraries/Servo/lib/arch
Add to build/include path: Project/libraries/Servo/arch

I still doesn't understand why your links are named lib/arch and arch, instead of arch/avr and src like in the Servo lib, something like that:

Link Project/libraries/Servo/arch/avr -> Arduino-1.5/libraries/Servo/arch/avr
Link Project/libraries/Servo/src -> Arduino-1.5/libraries/Servo/src
Add to build/include path: Project/libraries/Servo/arch/avr
Add to build/include path: Project/libraries/Servo/src

but besides that still I don't see any problem with this setup.
Why you say that the indexer would fail?

But let's go on.

One scenario I think of is the following:
I'm building a board  that has a "different" architecture than avr but is very much alike. Some libraries need to change but some are 100% compatible. Suppose this architecture is called "jantje"

Ok

For each library I support I create the folder jantje under [libname]/lib/ where I place my code.

you create for every lib the [libname]/arch/jantje/..... folder, for example Servo/arch/jantje/....

Assume that the Servo lib I need is 100% compatible with the avr lib. What I will do is create 2 files:
Servo.cpp which looks like this

Code: [Select]

#include ../avr/Servo.cpp
ServoTimers.h which looks like this

Code: [Select]

#include ../avr/ServoTimers.h

Oh well, I see your point, but since you're providing another architecture (even if is very close to avr), you'll probably do a better job to copy over those file in your private implementation instead of including with the relative path ../avr/.

Proposal: why you don't include the whole library? something like that:

Link Project/libraries/Servo/ -> Arduino-1.5/libraries/Servo/
Add to build/include path: Project/libraries/Servo/arch/avr
Add to build/include path: Project/libraries/Servo/src

note that you link the whole library but you add to the include path only the relevant piece for the selected architecture.

C

[Jantje]

Link Project/libraries/Servo/ -> Arduino-1.5/libraries/Servo/
Add to build/include path: Project/libraries/Servo/arch/avr
Add to build/include path: Project/libraries/Servo/src

note that you link the whole library but you add to the include path only the relevant piece for the selected architecture.

This is what  I do in my plugin and I would like to continue doing. However without the #ifdef in the source code as I propose this won't work. The problem here is that eclipse does not support negations nor environment variables for exclusions. for instance now I exclude /libraries/*/?xamples to exclude library examples from the project.
I can not do something like exclude !(/libraries/*/${architecture})
I can do those exclusions when the makefile is generated but I can not do it for the indexer.

I disagree that the links prove having a #ifdef per file is bad:
http://stackoverflow.com/questions/3627127/writing-cross-platform-c-code-windows-linux-and-mac-osx/3627208#3627208

instead of repeating yourself and writing the same #ifdef .... lines again, again, and again, you're maybe better of declaring the probe() method in a header, and providing three different source files, one for each platform. This also has the benefit that if you add a platform you do not have to modify all of your existing sources, but just add new files. Use your build system to select the appropriate source file.

http://stackoverflow.com/questions/14592179/c-cross-platform-development-to-avoid-preprocessor-directives/14592359#14592359

In essence, you are doing it wrong if you have a lot of #ifdef in the code itself.

I'm talking about 1 #ifdef per file. That is not a lot of #ifdef's in the code.

Note I don't object against a file/folder per architecture. I can see the benefit for certain project types.
I do object against code copying as you proposed I should do for my jantje architecture.
I do feel the comparison between arduino multi architecture libraries and linux is not 100% correct.
One of the responses you referred to states

.. (2) reduces mental effort to read it for someone who's only familiar with only one platform,  ..

The Arduino platform itself is meant to take away the mental effort of switching architectures to the developer. Therefore each developer becomes a multi architecture developer. The Arduino environment does a great job in supporting this work.
Where as a linux development environment is setup with focus to a developer who focusses on 1 architecture only.

You can clearly see the difference in the linux github link you send and the arduino library setup.
As linux is the project the folder for the code for a architecture is located at
[project]/arch/[architecture]/
Where in Arduino they are in
[arduino version]/libraries/[libname]/arch/[architecture]
As the libname is in front of the architecture it shows clearly that architecture is less foreground in Arduino world.
Note that in Arduino 1.5.2 the setup was more  linux like (libraries organized by architecture) and I could support it.

I still doesn't understand why your links are named lib/arch and arch, instead of arch/avr and src like in the Servo lib, something like that:

Link Project/libraries/Servo/arch/avr -> Arduino-1.5/libraries/Servo/arch/avr
Link Project/libraries/Servo/src -> Arduino-1.5/libraries/Servo/src
Add to build/include path: Project/libraries/Servo/arch/avr
Add to build/include path: Project/libraries/Servo/src

That is because I have dyslexia.  In other words it would be like you think it should be.
Edit: I would rename avr so I can have a link include. Just like I have variant for the pins_arduino.h

Jantje

[avenue33]

You can clearly see the difference in the linux github link you send and the arduino library setup.
As linux is the project the folder for the code for a architecture is located at
[project]/arch/[architecture]/
Where in Arduino they are in
[arduino version]/libraries/[libname]/arch/[architecture]
As the libname is in front of the architecture it shows clearly that architecture is less foreground in Arduino world.
Note that in Arduino 1.5.2 the setup was more  linux like (libraries organized by architecture) and I could support it.

Code: [Select]

[project]/arch/[architecture]/

That is exactly the solution I proposed in this very post dated May 12, 2013, already used by and Energia and chipKIT MPIDE.

For example, Energia manages two platforms: MSP430 and LM4F, with with one folder per platform / architecture, with everything related to it: cores, variants, firmwares, libraries, system, boot-loader. Same for chipKIT MPIDE.

[cmaglie]

Link Project/libraries/Servo/ -> Arduino-1.5/libraries/Servo/
Add to build/include path: Project/libraries/Servo/arch/avr
Add to build/include path: Project/libraries/Servo/src

note that you link the whole library but you add to the include path only the relevant piece for the selected architecture.

This is what  I do in my plugin and I would like to continue doing. However without the #ifdef in the source code as I propose this won't work. The problem here is that eclipse does not support negations nor environment variables for exclusions. for instance now I exclude /libraries/*/?xamples to exclude library examples from the project.
I can not do something like exclude !(/libraries/*/${architecture})
I can do those exclusions when the makefile is generated but I can not do it for the indexer.

Ok, so its the eclipse plugin that is not much configurable, I thought that it would index only the folders included in the build path (as reasonably expecting) and not the entire project, but this is not case, good to know.

Then, you should go back to the first solution I proposed and link the two paths:

Link Project/libraries/Servo/arch/avr -> Arduino-1.5/libraries/Servo/arch/avr
Link Project/libraries/Servo/src -> Arduino-1.5/libraries/Servo/src
Add to build/include path: Project/libraries/Servo/arch/avr
Add to build/include path: Project/libraries/Servo/src

(you can name the linked folders at your wish, of course)

This solution involves an acceptable amount of work you wish to dedicate to your plugin?

[bperrybap]

Here are my comments.
My overall comment summary is that this specification does help some issues
but also creates issues, and that the issues it solves are mostly for the
benefit of Arduino team and it's IDE release which is static for
a given release.
The 3rd party world is much more complex and has different wants & needs.
Because of this, the existing .properties format is lacking critical
information fields to be useful for adding 3rd party cores and libraries.
The current format also appears to start to break down when adding 3rd party cores
and libraries.

A big missing concept is to separate the .properties for the library
supplied with the library before it is installed with that of an
IDE private post install library information and directory structure.
i.e. the IDE should take information from a library as it is being
installed (or removed) and use it to create/manage a private "master" "information file"
and directory tree for the library.
As it is today, it is a real mess and requires lots of external merging, updating,
and cooperation by 3rd parties and external tools
to make it work since it appears that IDE (or future library manager)
is trying to take a hands off approach to managing/merging the information during
install/remove of the libraries.
The type of cooperation among 3rd parties necessary to do this type of synchronization
of the libraries .properties file and directory structure
is very unlikely to actually occur.

I will hazard a guess that this new library structure has the potential to blow up
worse than the decision made at the 11th hour on the 1.x release to intentionally break 100%
of the pre 1.x libraries, particularly if the Arduino team eventually takes
a similar hard-line stance on trying to force everyone to adopt it
by removing support for libraries that don't adopt it.

I also observe that it is very interesting the Arduino team has chosen not to
use this library specification and directory structure for its own core
libraries.  In my view, if this specification was good enough, it could
also be used on the core code libraries, because after all, the core code
library is essentially just another library.

In looking closer, I'd like to first look at the functionality offered rather than
some of the deeper issues like include paths and command line compatibility.

The .properties file has a field called: core-dependencies
What isn't clear about this field is exactly what it is.
Is the core-dependencies referring to the vendor/mantainer mentioned on the
1.5 3rd party Hardware spec (HardwareFolders structure)?
To me this makes the most sense since in the architecture folders are directly under
a directory name that seems to match the "core-dependencies" name. ("Arduino")
It would be helpful if the terminology were more consistent since the
library .properties spec and the hardware folders directory structure
are directly related.

Now things start to get complicated really fast.

Core versions are supported in the .properties file.
So where does the "core" version come from?
The 1.5 library spec shows it as being part of the core-dependencies.
Hopefully it is not the IDE version.
The core version really needs to be tied
to the actual architecture core code not to a revision of a GUI shell/wrapper around
the tools.
It should be possible to have different  cores that are at
different versions installed on an IDE.
This will be particularly true when it comes to 3rd party cores.
For example, what if a user wants to load up a 1.0 or maybe even a pre 1.x
pic32 core using the 1.5x IDE?
It should be possible to do that.
To me, the core-dependencies revision is very ambiguous.
The platforms.txt file down under the architecture file
(where it should be because it documents the revision of that core)
has a version in in it.
Is the platforms.txt version used for anything?
So the questions becomes what is the core-dependencies version,
where does it come from, and how is it used?

The .properies spec supports multiple architectures.
How do you match up which core-dependencies goes with which architecture
when there are multiple of each?
Also, if there are multiple cores supported, not every architecture is supported
or even exists under each "core" assuming "core" means vendor/maintainer in
the 3rd party hardware spec sense.

The current .properties spec assumes that all the examples provided
will work with all the combinations of cores and architectures that the
library supports. This may not necessarily be the case.
What if certain examples only run on certain cores or architectures,
or potentially only certain chips within certain architectures of a given core?
There is currently no way to specify which cores or architectures or chips/boards
an example actually works with.



So now some questions on how to actually use it in real life situations.

1) A 3rd party library that only works on a specific AVR chip.
An example of this might be a library that provides some USB capability but
only runs on the 32u4.
What goes in the .properties file to specify that the library only
works on 32u4 based boards?
As it is today, this can't be done. A user will see it on all avr based boards and get
errors on all non 32u4 boards.

BTW, The existing 1.5.4 examles have a related problem, in that there are examples
that error during compling on any board other than leaonardo.
(Seems like point of all this .properties stuff was prevent this kind of stuff)

2) A 3rd party would like to provide an enhanced version of a library
that replaces an IDE provided library but only when a certain (chip) is used.
This is similar to #1 but replaces the library supplied with the IDE
when a board of a given chip is selected.
An example of this might be a softserial replacement for atmega328.

3) 1.x vs 1.5 libraries.
The issue here is that multi-arch 1.5 libraries will not work on 1.x.
This has now doubled the amount of work a 3rd party developer has to do
if they wish to support both.
The simpler solution will be to just support one or the other.
Developers may choose to use 1.x (I know I will) given that option allows
the code to run on both IDEs.
My concern is that the Arduino team will once again take the hard-line
approach and disable the 1.5 IDE from supporting pre 1.5 libraries in
order to force its use.

4) 3rd party libraries for specific cores or boards.
Consider a case where there is a 3rd party library that only works
on a specific core or a specific board.
Perhaps a vendor has created their own 3rd party "duino" board and has provided
a custom library for it.
The current .properties does now allow specifying down to that level.

5) multiple 3rd party libraries with the same name for different cores/chips/boards.
This is possible but in order to support this, the IDE (library manager) needs to be
smart enough to allow these multiple libraries by maintaining the library tree
vs just blindly taking from the library itself.
Say for example, it should be possible to install multiple core/chip/board specific
libraries and have the IDE (library manager) keep track of it so that the proper
library only shows up and is used when the associated board is selected.

6) It appears to make it very difficult to share code with Non-Arduino projects
I have concerns that this structure will make it very difficult to have
multi arch code that is shared between Arduino and non Arduino environments.
I have a glcd library that currently works on m168/338, Leonardo, Mega,
Chipkit boards, Teensy3, mighty1284p core, and several others.
It also has chip specific i/o routines for many different processors that it uses to speed up the i/o
because of the slow digitalxxx() core routines.
I also am in the process of creating a "bare metal" option to allow
it to be used in raw C++ environments, without Arduino.
At this point in time,
I have no intention of converting it over to this 1.5 library spec as it doesn't
make things easier, and would precluded it from running in several of the other
environments.



I guess my message in all this is that my view of the new 1.5 library spec
from functional point is that while it helps out in some cases, it doesn't go nearly
far enough to solve many of the real-world 3rd party issues.

I also believe that from a implementation stand point, it looks very bleak
to it working if a library needs to come from or be supported by different people
or organizations.

Overall, I have many concerns about this specification.


--- bill