Go Down

Topic: Comments on Arduino 1.5 Specifications (Read 56550 times) previous topic - next topic

Jantje


.. (and probably jantje would kill me :)),..

Don't worry. I'm really good at architecture/analyses/design/problem solving but my skills for killing are lacking.
So you are safe due to a lack of skills on my side.  ]:D
Jantje
Do not PM me a question unless you are prepared to pay for consultancy.
Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

cmaglie

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

C.

bperrybap


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:
Quote
why you're so concerned about that yet.


Eventually "yet" arrives, and from my perspective, it was poorly handled
on the 1.0 release.
When 1.0 was released,
several things were changed at the last minute that broke
backward compatibility with existing libraries.
100% of the 3rd party library code that was stable for MANY years and was working
on all the beta releases of 1.0 was suddenly made obsolete and no longer compiled
on the final 1.0 release.
The Arduino team deliberately made the decision to break 100% of the existing 3rd party library code
to force everyone to update their libraries. There were easy ways to make most of the existing code
continue 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 code
and 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, Teensy
All 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 architecture
and are a s/w only compatibility matter.
In those cases you can have a similar situation as to what you mentioned above, using
an ifdef around minor code differences.
For example, there can be slight differences as to how AVR vs ARM vs pic32 handle
their standard i/o which can affect a library.

tool/board/architecture/chip portability mapping is never an easy thing to resolve
and 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 useful
in 3rd party environments.
I'm concerned that the 3rd party guys may end up with a system that is different but still doesn't
solve many of their needs.
To a large extent I think this effect is quite natural in that the Arduino team is focused
on their release - as they should be - so there isn't really a focus
on 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 may
work 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 a
difficult hurdle for the 3rd party community to convince the Arduino
team to pursue that path.

I brought some of this up earlier but here is some additional detail
a 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 a
way to deal with this.
The 1.5 hardware spec clearly shows how different vendors create their own subdirectory and
then can create architectures below. But in the .properties spec, there is no reference to these
core "vendors"/maintainers
Also the related 1.5 hardware spec doesn't go into details on where the vendor should put his tools
for 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 but
were actually different.
Having the all the build tools under the architecture directory allowed the chipKIT support to be
added 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.5
all 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 many
of the properties from the board.txt file.
That way a library or sketch (assuming there is an optional .properties for sketches) could specify anything
it wants as a dependency


We 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 of
libraries or examples in the IDE GUI for the user, then no, the 3rd party tools may not have to support this since
they 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 party
tools 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?



bperrybap

Quote
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.


I think that what could go a long way is to ensure that very simple 1.5 libraries
still work on 1.0 because I don't see everyone immediately jumping on the 1.5 bandwagon.
By creating this capability, you could get a quicker adoption of the 1.5 library format by
library developers since they could now create and maintain a library that works on both
1.x and 1.5 without having to avoid the newer 1.5 format.

For example, if a 1.0 library could simply add a .properties file and
the common code didn't have to be in src then simple 1.5 libraries
could still work on 1.0 but 1.5 could get and use the additional information
from the .properties file.

OR as an alternative (and I mentioned this earlier as well),
the IDE/library manager should maintain its ".properties" stuff separately from what
may be provided by the library. So the IDE takes some information
from the library and uses it to install the library in the IDE.
Or another option for importing/installing the pre 1.5 library files would be the query the user
for the information and create the needed IDE ".properties"  stuff during
the install process.

I think many things are possible and I'll be happy to participate in the process
of coming up with solutions.
I also think that there are several others that have responded in this thread
that have an interest in participating to come up with something better.

The key is coming up with a list of wants & needs for this type of capability.
And people need to be very clear at understanding the difference between
their true needs and their wants.
Once there is discussion and a exchange of these ideas, it becomes much
easier to decide on the how to proceed: Try to cover all the needs first,
then try to integrate as many of the wants as you can given the
timing and resources available.

--- bill


bperrybap

#64
Oct 23, 2013, 06:55 pm Last Edit: Oct 23, 2013, 07:04 pm by bperrybap Reason: 1
Cool,
Just noticed the post about the developers thread.
We can all continue over there.

EDIT:
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?

--- bill

avenue33


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


Ok, initial post awaiting approval.

pjrc

#66
Oct 23, 2013, 07:45 pm Last Edit: Oct 23, 2013, 07:49 pm by Paul Stoffregen Reason: 1
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.


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:

Quote

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.


I'd like to point out some language near the end of the spec, which might be the source of concern:

Quote

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.


Maybe this part of the spec should be updated, if you're really committed to keeping the old format supported?

Jantje

Whether it is off-topic or not (I think it is on topic). but:

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!


I knew about the developers list but I was not aware you could reread the list on google. To me mailing lists are terrible for discussions.
It seems the new web site does mention the google groups where the old one only mentioned the mailing list.
So you are not the only one asking the question.

To be honest: As the Arduino core team has not shared any documented process on releasing specs; I feel any remark like "you should have commented on the developers mailing list." is not constructive. Where does it say "that is the way?" And why is there a forum named "Development :: Suggestions for the Arduino Project" if suggestions for improvement are not to be posted here?

I know I'm quite a formal guy and the open source is mostly anti-formal. But as you can see: people ask "How could I have known?" the only correct answer is "Luck" and "you can increase you Luck by increasing your attendance".
Just to state the obvious: This has nothing to do with cmaglie but with the typical growing pains of any organisation.

On topic: I made a script that adds the ifdefs. That makes it work. But the script is unix only for now and it is a shame it doesn't work out of the box. Maybe Arduino can consider running this script before making the installation files. That has the benefit that the ifdefs are not there for the "library developers".
To be honest: I don't expect a positive response because the packaging process is mostly already complicated and it may also impact testing.

Jantje
Do not PM me a question unless you are prepared to pay for consultancy.
Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

avenue33

#68
Oct 23, 2013, 08:05 pm Last Edit: Oct 23, 2013, 08:08 pm by avenue33 Reason: 1
Jantje

Thank you for saying loud what I'm thinking actually. This is just another example of what I've already pointed at, the lack of consideration and lack of respect towards Arduino contributors from the Arduino team .

Anyway, the question is now: How to use standard tools as GCC to compile a sketch with the new library structure?

The Arduino IDE avoids the issue by performing under-the-hood work. I could have tried to mimic that on Xcode but, let's face it: Wouldn't be easier to consider a sketch as a plain C++ project?

When Arduino is going to understand that, behind the limited IDE, there's a framework worth considering and promoting?

Now, there are so many interesting boards outside, cheaper and more powerful, ...  

bperrybap


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.

Paul,
Directly from the 1.5 library spec page in the IDE behavior section:
https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification
Quote
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.

And in Cristian's first post to this thread:
http://forum.arduino.cc//index.php?topic=165827.msg1384527#msg1384527
Quote
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.


Form that language I interpret it to be a desired intent/goal to have the IDE filter out
libraries and sketches that are not supported on the selected board.
In fact you see this behavior already today in the 1.5.4. IDE.
Select a DUE board, then click
[File]->[Examples] ->[Scheduler]->MotorKnob
This is an example in the Scheduler library.
Now change the board to "Arduino Uno".
The Scheduler library is now gone.
The reverse happens for the "Bridge" library which is AVR only.
I can go in and modify the architectures value in the .properties
file for the library and the IDE uses the information.
So clearly the intent is that the IDE is going to use this information
to determine what is filtered for the user.

While I think it is a good goal and would be a great capability for the IDE
to support for its Arduino users, the information in the .properties file outlined in
the current 1.5 library spec is simply not capable of providing that capability
across the 3rd party cores.
And that is why I brought up all the real-world examples of how the
current spec falls down.


Quote

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.


My point exactly. And that is also part of the reason for my concern.
I worry that the Arduino Team might resort to a heavy handed approach again
to force its adoption like it did in the 1.0 release.

Quote

Cristian, I'm really glad you said this:

Quote

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.


I'd like to point out some language near the end of the spec, which might be the source of concern:

Quote

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.


Maybe this part of the spec should be updated, if you're really committed to keeping the old format supported?


I totally agree with Paul here. I saw that language very early on when looking over this 1.5 library stuff
many months ago. That language pretty clear states that there is a goal
to remove support for the pre 1.5 libraries.
The first thing I thought is UH OH... Here we go again.
It's going to pre 1.0 vs 1.0 libraries all over again.


--- bill

pjrc

Ah, yes, you're right.  I overlooked the "IDE behaviour" section.  It is right there!

As a maker of a 3rd party boards on a different "architecture", this worries me somewhat.  My hope is most libraries will use "architectures=*".  But a very likely scenario is "architectures=avr", even when the AVR specific stuff can be emulated (as Teensy 3.0 does for many commonly used AVR-isms).  I definitely don't want stuff that "just works" made invisible, only because the original library author only tested on a single platform.

bperrybap

Paul,
What is your understanding of the "architectures=" field?
OR what does  architectures=avr really mean?
I brought this up earlier but I think it got lost in the noise.

Suppose the Teensy or maniacbug1284p core is updated to be recognized by Arduino 1.5.4
What then?
I can't resolve in my head what the "architecture" field means given the current 1.5 hardware spec
vs the 1.5 library spec.
The hardware spec talks about vendor/maintainer but the 1.5 library spec
talks about "core-dependencies".
The hardware spec talks about "architectures" which live under a vendor/maintainer directory.
So if the "core-dependencies" in the .properties file refers to a vendor/maintainer core and
its sub architectures, how does a library refer to a specific architecture within a specific vendor/maintainer core?
i.e. how would a library specify that it only runs on the Teensy or maniacbug1284p core?
OR what about a core that works on any AVR architecture processor core regardless
of the vendor/maintainer:
Arduino, Teensy, manicbug1284p, Attiny.

In other words how do 3rd party cores get installed in 1.5 and
then how do libraries specify their dependency on these 3rd party cores or their
sub architectures using the .properties file?

And for products like Teensy that include Teensyduino.
Within Teensyduino,  is "teensy"  the vendor/Maintainer with sub architectures of avr and arm?
And if so, how does a library .properties file for an "AVR only" library
specify that it can only run on the boards that use the Teensy avr core?

As it is today, it does not appear that the .properties file can handle
3rd party cores dependencies very well.

One possible solution might be to alter the architectures field.
Perhaps something like:
architectures: vendor/architecture (optional-version)

That could potentially even allow something like:
architectures: */avr
To specify any vendor that has an "avr" architecture.

--- bill


Jantje

When I started to look at the implementation of the library spec in 1.5.4 (I mean look at the sub folders of libraries) I was struck by the tag
Quote
"architectures=*".

It goes with what Paul already stated several times about "There is not 1 person maintaining the library".
Basically the properties file is common. So it depends on 1 person to maintain. That one person can decide on which platforms a library can/may run  :smiley-eek:.
The same counts for other properties.
What struck me the most was that Arduino mostly works on folder names (like for avr and sam in the hardware/arduino folder) and here decides to go for a "described in file" specification. And that file is under control of Arduino  :smiley-eek:.
The reasoning is at least "strange"  $).

And then I come to something difficult to explain. I mean there are facts (like It is unnecessary hard to implement in eclipse ) and there are ideas behind a approach (Like it should be easy for the library builders and we don't care about tool builders).
The document explains (though not explicit enough to me) the aim but not the reasoning/ideas behind the "solution(s)".

In this particular case my "idea behind the solution" is very oo oriented.
First of all :There are many things that don't fit the model  I'll describe; so I'm sure this model was not in mind when the design was done.
In a oo world (surely C++) there is definition and implementation. so I see a definition which is in the src folder  :smiley-eek: and a architectural implementation source code is in the lib/[arch] folder  :smiley-eek:. (the  :smiley-eek: for the folder names)
That would mean that the implementation references the definition but the spec says
Quote
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:

Which I understand as both folders are  part of the build path and the include path. Why would I need 2 folders in build and include when 1 is implementation and one is definition?
In this same idea there should be a properties file for each implementation stating which architecture it supports. If there is a conflict the specific setting should overrule any more generic setting as we do with boards.txt and platform.txt.
That solves the "I write a definition but I don't know the implementation" problem but introduces a new one.
What if 2 (or more) library implementations state they can implement your boards architecture?
The most common sense would be that the end user can select the "wanted" library implementation.
This can very easily be implemented by having a define in the properties file. In that case selecting a library implementation means adding a define to the compile path and including the correct header.
This also solves (partly) the forced code duplication problem the current spec has. This because a single folder can hold endless architectures.
I know Arduino has something with ifdef but I feel this is a more robust and easy to implement solution covering more cases as the current spec.
I also realize this is completely incompatible with the current folder names. For instance the current [architecture] folder is prbably better a [implementer] folder. The src folder can not contain code but only definition....

As we are at it.
One of the things I liked about the Arduino libraries (pre 1.5) is that 1 library=1 include in the ino file.
The 1.5.4 includes all the headers in the src folder.  for 1 library (I don't remember its name) there is even no file with the library name. I think this will confuse the newbe (and puzzle  even the more experienced like me).
My preference goes to 1 include in the ino file with the library name (The name of the folder and maybe preceding folders) for 1 library.  

Jantje


Do not PM me a question unless you are prepared to pay for consultancy.
Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

Jantje

bill
I guess you are asking the wrong person on how it is currently implemented.
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)

Paul 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.



On the hardware/[arch] folder
I 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)
I think it is not compliant with following points in the library guide line
Quote
Be kind to the end user.
Match your API to the underlying capabilities. You don't want to expose implementation details to the user
Organize your public functions around the data and functionality that the user wants.
Use full, everyday words.

But it is not a library? or is it? ]:D

Jantje
Do not PM me a question unless you are prepared to pay for consultancy.
Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

bperrybap


bill
I 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 flaws
in the current .properties specification with respect to trying to specify 3rd party cores
or 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.1




Paul 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 the
flexibility offered by the platform and board files. I had to completely change things for chipKIT but the flexibility was
there for me to change all the commands around when chipKIT boards were selected without
having to change anything in the Arduino JAVA IDE code.



On the hardware/[arch] folder
I 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 toolsets
are required to develop across the different processors.
As far as the end user goes, most of what are discussing is completely hidden from
the normal end user.
The user doesn't have to know any of this as long the system allows a library
to specify which environments it works in.
But to do that the library writer and core developer has be very familiar with these
differences and how to configure and specify what works together
AND the system must be capable of allowing enough information to be specified
to ensure that the system can select the proper tools and libraries once the user
specifies 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 which
cores and sub architectures within a core are supported by the library when
3rd 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 issues
before the implementation issues.





Go Up