Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix libraries priority selection (again)#574

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
cmaglie merged 4 commits intoarduino:masterfromcmaglie:fix-lib-prio-again
Feb 6, 2020

Conversation

@cmaglie
Copy link
Member

This PR changes again the lib priority selection to improve backward compatibility. Now the algorithm should be (hopefully) 100% compatible with legacy algorithm used in thearduino-builder.

The priority is determined by applying the following rules, one by one in this order, until a rule determine a winner:

  1. A library that is architecture compatibile wins against a library that is not architecture compatible
  2. A library that has better "name priority" wins (see below for details)
  3. A library that is architecture optimized wins against a library that is vanilla
  4. A library that has a better "location priority" wins (see below for details)
  5. A library that has a name with a better score using "closest-match" algorithm wins
  6. A library that has a name that comes first in alphanumeric order wins

Usually the first four rules are enough, the rule 5 is rarely applied and the rule 6 is even more rare. Anyway they are there to not leave the selection process undefined even in those extreme cases.

@per1234 could you check if this solves#572?
I think that this issue alone calls for another release of the Arduino IDE.


Details about rules:

A library is consideredcompatible with architectureX if thearchitecture field in library.properties:

  • contains explicitly the architecureX
  • contains the catch-all*
  • is not specified at all.
    (see table below for an example)

A library is consideredoptimized for architectureX only if thearchitecture field in library.properties contains explicitly the architecureX.

architecture field inlibrary.propertiesCompatible withavrOptimized foravr
not specifiedYESNO
architectures=*YESNO
architectures=avrYESYES
architectures=*,avrYESYES
architectures=*,esp8266YESNO
architectures=avr,esp8266YESYES
architectures=samdNONO

The "name priority" is determined as follows (higher is better):

PriorityRuleExample forServo.h
5The name match the include 100%Servo
4The name match the include 100% with a-master suffixServo-master
3The name has a matching prefixServoWhatever
2The name has a matching suffixAwesomeServo
1The name contains the includeAnAwesomeServoForWhatever

The "location priority" is determined as follows (higher is better):

PriorityRule
4The library is in the sketchbook
3The library is bundled in the board platform/core
2The library is bundled in the referenced board platform/core
1The library is bundled in the IDE

@cmagliecmaglie requested a review fromper1234February 3, 2020 20:15
@cmagliecmaglie self-assigned thisFeb 3, 2020
@cmagliecmaglie added this to the0.8.0 milestoneFeb 3, 2020
@per1234
Copy link
Contributor

I confirm this does fix#572 for me. Thanks!

Excellent documentation! Should we publish this information to a more "official" location? I thinkhttps://github.com/arduino/Arduino/wiki/Build-Process would be the most appropriate location in our existing documentation.

Regarding the IDE release, I like the idea of moving quickly to resolve serious bugs, though I know the release verification process is a lot of work for you. Some other bugs that would be nice to get resolved before the release:

@cmaglie
Copy link
MemberAuthor

Excellent documentation!

Thanks! After rereading it this morning it really looks like a draft-I-quickly-written-just-after-fixing-the-issue. It surely need some rewording with a better idiomatic english :-)

Anyway it's nice to see how nice and linear the algorithm turned out to be after straightening and refactoring the legacy code.

Should we publish this information to a more "official" location? I thinkhttps://github.com/arduino/Arduino/wiki/Build-Process would be the most appropriate location in our existing documentation.

Sure, can you take care of it?

@per1234
Copy link
Contributor

I have added the library priorities documentation to the Build Process wiki page:
https://github.com/arduino/Arduino/wiki/Build-Process/_compare/bbff14b72ab76c35b0e40de31853a9e027511269...5046ffe2a448f259bff6315896e054089e921f74

In addition to some minor rewording and fixing of typos, I made the following additions/changes:

  • Expanded it to be a high level overview of the dependency resolution process
  • Changed "name" to "folder name" to differentiate it from the library.propertiesname, which does not influence library selection priority
  • Removed priority numbers from tables. I felt they did not add anything of value, and made the documentation appear slightly more complex than necessary.
  • More specifically defined locations

I'm happy to make corrections or improvements if anyone has feedback for me (and, of course, feel free to edit the wiki directly).

@cmagliecmaglie merged commitfe48668 intoarduino:masterFeb 6, 2020
@cmagliecmaglie deleted the fix-lib-prio-again branchFebruary 6, 2020 11:05
cmaglie added a commit to arduino/arduino-builder that referenced this pull requestFeb 11, 2020
- Fix library priority selection (again)arduino/arduino-cli#574- Improve precompiled libraries handlingarduino/arduino-cli#512
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@per1234per1234Awaiting requested review from per1234

1 more reviewer

@rsorarsorarsora approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

@cmagliecmaglie

Labels

None yet

Projects

None yet

Milestone

0.8.0

Development

Successfully merging this pull request may close these issues.

3 participants

@cmaglie@per1234@rsora

[8]ページ先頭

©2009-2025 Movatter.jp