Library Manager update overrides bundled patched libraries

[per1234]

Library Manager installs libraries to the sketchbook/libraries folder. This folder takes precedence over the mighty-1284p\avr\libraries folder so after a user updates the standard version of any of the Mighty 1284P patched libraries using Library Manager the unpatched library will be used instead of the patched library. The only solutions I can think of are:

1. Instruct the users to do the updates but then to move the updated libraries to arduino/libraries where they will not take precedence over mighty-1284p\avr\libraries when a Mighty 1284P board is selected.
   • This is probably the best of the 3 but a bit complex.
2. Instructing the users to not do Library Manager updates of any of the libraries that have been patched in Mighty 1284P.
   • This is a bad solution because updates are a good thing.
3. Rename all the patched libraries.
   • This will require the user to change their includes.

This issue is being discussed here: arduino/Arduino#4064 but of course any solution found there will only be available in Arduino IDE 1.6.6. If you let me know how you want to handle this issue I'm willing to do the work and submit a pull request.

[per1234]

4. Merge Unique name value in library.properties #23 and then have the user install the patched libraries to sketchbook/libraries. Then when a Library Manager update of one of the patched libraries is done the update will be installed as sketchbook/libraries/arduino_xxxxxx instead of overwriting the patched library because of the different name in library.properties. Because the installed update has a different folder name than the include it will take lower priority than the patched library.

• The downside to this is that the patched libraries will be always used instead of only when a Mighty 1284P board is selected and the patched libraries tend to be pretty out of date so the user may encounter old bugs or lower performance when using non-Mighty 1284P boards even though they think they have the most recent version of the libraries installed.

[pico--]

Of these options, I think 1 is the only viable one. The installation
instruction will have to be extended with a caveat for the user to check
if there are libs installed under the sketchbook/libraries folder, and
where to move them if that is the case. And also to remember the same
operation will be required if doing a Library Manager update in the
future that results in libs installed under the sketchbook/libraries folder.

I would also suggest some explanation be included as to the precise
nature of the problem regarding search precedence, and why the moving of
the sketchbook/libraries folder will resolve the problem. We should also
mention that this problem may not affect future version of the IDE if
the Arduino development team come up with a less clunky approach to
Library Manager in the future.

What do you think?

On 11/2/2015 9:03 PM, per1234 wrote:

Library Manager installs libraries to the sketchbook/libraries folder.
This folder takes precedence over the mighty-1284p\avr\libraries
folder so after a user updates the standard version of any of the
Mighty 1284P patched libraries using Library Manager the unpatched
library will be used instead of the patched library. The only
solutions I can think of are:

1. Instruct the users to do the updates but then to move the updated
   libraries to arduino/libraries where they will not take precedence
   over mighty-1284p\avr\libraries when a Mighty 1284P board is
   selected.
   • This is probably the best of the 3 but a bit complex.
2. Instructing the users to not do Library Manager updates of any of
   the libraries that have been patched in Mighty 1284P.
   • This is a bad solution because updates are a good thing.
3. Rename all the patched libraries.
   • This will require the user to change their includes.

This issue is being discussed here: arduino/Arduino#4064
arduino/Arduino#4064 but of course any
solution found there will only be available in Arduino IDE 1.6.6. If
you let me know how you want to handle this issue I'm willing to do
the work and submit a pull request.

—
Reply to this email directly or view it on GitHub
#24.

[per1234]

Sounds good to me. Should I wait a few days to see if anyone else has input before going ahead with the documentation update?

[pico--]

Just go ahead at whatever pace suits you, I think. If anyone
subsequently comes along with a better idea, that would be great -- we
can always take that up as an alternative. But I suspect the options at
present are limited to pretty much as you've outlined.

Thanks for taking the initiative on this.

-Mark

On 11/2/2015 11:59 PM, per1234 wrote:

Sounds good to me. Should I wait a few days to see if anyone else has
input before going ahead with the documentation update?

—
Reply to this email directly or view it on GitHub
#24 (comment).