You did answer one thing that I thought was probably the case:
The "architecture" names are global across all vendors.
As far as my question goes about how a 3rd party library can specify which core to use
I think you have missed part of the issue.
What I was questioning was more how does a library specify that it
only works with certain specific cores?
For example, suppose the library only works on a specific vendors core
and none of the others - even if they are the same architecture.
i.e. maybe something only works on the pjrc teensy avr core.
Then there is the case where a library only works on a certain chip.
Maybe it only works on a board that has a 32u4 on it
or maybe it only works on board with a m168 or m328.
Libraries only working on specific chips is quite common.
This common real-world scenario can't be handled by the current .properties spec.
What I'm saying is that I wasn't concerned that the spec could get
a library to work when the user selected a board that supported it even when it was
on a 3rd party core or 3rd party board.
It was more that the there is not enough information to prevent the user from trying to use
it on boards that can not support it.
It was my assumption that this was a goal of the .properties stuff in the first place.
To provide enough information to allow the IDE to filter out and not show
libraries and examples that will not work on the board the user has selected.
And if we going to allow the user to pick libraries and examples that won't work
on and/or error off during compilation for the selected board,
we are missing out on what could be done because that is essentially what we have today.
And then what about sketches?
Sometimes users go off and download sketches.
Currently there is no way for a sketch author to specify which cores or libraries may
be required other than with comments in the code.
We see many users posting questions in the forums asking why the sketch or example
that they download isn't compiling because of missing libraries or it not working
on the board that they have.
I guess what bothers me is that the current spec looks like it is only capable of
solving some of the issues while ignoring several current real world issues, and I don't really like partial solutions.
With respect to "cores" and core-dependencies,
I think I now see the problem.
The Arduino team point of view seems to be that the environment as fairly consistent
for a given release.
And for them this is case because they ship a full blob that is all done at the same time and is all the same
level/version. The Arduino team really doesn't have to deal with past releases in their libraries.
However, once you enter into the 3rd party world, this is no longer the case.
In the 3rd party world, a core or library is done and while the Arduino IDE and its cores advance
the 3rd party library and core may not be updated right away or at all.
Also, a 3rd party library and core cannot always depend on only using the latest Arduino release
the way the Arduino team can with its libraries.
Many 3rd party libraries today are capable of running on pre 1.x as well as 1.x
and even 1.5 (by using appropriate ifdefs).
And this is why backward compatibility is so important to the 3rd party world,
whereas to the Arduino team they have no need for backward compatibility
because they essentially re-do everything all at once on each of their releases
and get to leave old releases behind.
This is why the 1.0 library change was no big deal to them, while it was a HUGE deal
the 3rd party developers.
So back to why this matters for the "core-dependencies".
After seeing the response to Paul's question it appears that
there really is no vendor/maintainer core dependency in the spec at all.
The "core-dependencies" is actually a version of a architecture core within all the vendors cores.
There appears to be an assumption that all the cores of a given architecture will/must be at
the same version.
I had asked about about what the "core-dependencies" really meant in previous posts.
My assumption had been that it referred to the vendor/maintainer to allow the library
to specify which vendor's core it worked on.
But now it appears that this is really a revision of the "arduino" core within all the architectures.
Note: The naming seems VERY confusing in that there is a "arduino" vendor
and subdirectory in the hardware directory and now we have another "arduino" name
that means something completely different.
What really confuses me is that the library spec says:
core-dependecies - the core on which this library works on (multiple cores can be specified)
So my assumption was "cores" like Teensy vs ManiacBug vs Arduino etc...
But this seems to not be the case.
It appears that the "core-dependencies" values are referring to the revision
of an architecture core.
While I can see the use for the ability of the library to ensure that a particular "arduino" core API
is supported within a given architecture core, my concern is that it appears to be tracking the
IDE revisions because that's how thins are released for the Arduino team code.
This concerns be greatly.
It also does not appear to allow using or requiring different versions for the different architectures.
Consider this case:
Down the road the "arduino" API advances and you have a situation
with multiple maintainers for a library.
the latest "arduino" API is now 1.5.9
The library previously supported an avr architecture and works on any API back to 1.5.0
Now support is being added for sam but the sam developer decided to use features
So now the sam code requires >=1.5.9 but the avr code can run on >=1.5.0
There does not appear to be a way to specify that.
This is why earlier I brought up the possibility of specifying the core version
on the architecture= values.
It allows the library to run with mismatched versions on different architectures
So you could have:
architectures = vendor/architecture/core (version)
This would support most of the capabilities I've been talking about
including the ability to specify individual vendors cores.
(It wouldn't handle the library only working a specify chip).
So for the above example:
architectures=*/avr/arduino (>=1.5.0), */sam/arduno(>=1.5.9)
which is any vendor with "avr" architecture "arduino" core and then
the desired/needed revisions of that core.
For a library that only works on Pauls teensy avr core:
For a library that only works on maniacbug
For a library that works on any "arduino" core >= 1.5
architectures: */*/arduino (>= 1.5.0)
(any vendor, any architecture, but requires arduino core >= 1.5.0)
To me this seems to make more sense than the current
core-dependencies since I simply can't resolve how that really
works once you have more than one version and multiple architectures.
or perhaps some sort of hierarchical structure like what is in
the platform and board files to allow the specific architecture of
board preferences override the more general settings.
For sketches, I think it would seem logical to use the same
type of .properties file.
The sketch would have its library dependencies,
and those libraries may have additional dependencies
to form the final dependencies for the sketch.
All that said, I think that there needs to be more thought to come
up with a way that allows a library to specify that it only works on
a specific chip.
Perhaps using the property values like what is in the board and platform
files is the answer.