library resolution is wrong when a core is installed both manually and via boards manager (which is common and recommended)

[ObviousInRetrospect]

Describe the problem

Some cores recommend doing a board-manager install to install toolchains and then manually installing the core into ~/Arduino/hardware/.

After doing this, the board selection correctly says megaTinyCore (in sketchbook)

However, I was chasing down a bug I previously fixed in head of tree that re-appeared and discovered that Arduino was loading libraries from the board-manager version while claiming to be using the SketchBook version.

https://arduino.github.io/arduino-cli/0.21/sketch-build-process/#dependency-resolution documents the dependency resolution order and the behavior is not consistent with the documentation.

To reproduce

launch IDE 2.0
Install megaTinyCore via board-manager
close IDE 2.0
Insert a bug a library. For example #error("This file should not be in use") in Comparator.h (see below for a full path). Or in this case, leverage one that was already there but fixed in head of tree. (the version that I used is blocked from installs so use the #errror path. 2.5.11 or 2.6.1 depending on whether 2.6.1 is available when you go to reproduce.)
Install megaTinyCore in sketchbook (git clone https://github.com/SpenceKonde/megaTinyCore.git)
launch IDE 2.0
select a board from the core labeled (in sketchbook)

Attempt to compile a sketch that includes < Comparator.h >

get an error indicating a path that should not be used caused an error. Copy paste the error into something with a readable color:

In file included from /Users/gbr4/Documents/Arduino/soilmoist3224b/soilmoist3224b.ino:19:0:
/Users/user/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.6.0/libraries/Comparator/src/Comparator.h:323:5: error: 'in_comparator' does not name a type; did you mean 'Comparator'?
     in_comparator::p::inputP_t     input_p        = in_comparator::p::in0;
     ^~~~~~~~~~~~~
     Comparator
/Users/user/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.6.0/libraries/Comparator/src/Comparator.h:324:5: error: 'in_comparator' does not name a type; did you mean 'Comparator'?
     in_comparator::n::inputN_t     input_n        = in_comparator::n::in0;
     ^~~~~~~~~~~~~
     Comparator

exit status 1

Compilation error: exit status 1

Expected behavior

the library installed under the sketchbook version of the core to be used in preference to the one installed by boards manager. The #error to not be brought into the compilation.

This was tested both against a vanilla 2.0.0 install and with the current nightly dropped in.

Arduino CLI version

arduino-cli Version: 0.27.1 Commit: a900cfb Date: 2022-09-06T16:44:27Z. and arduino-cli Version: nightly-20220917 Commit: 7d1916d Date: 2022-09-17T01:35:38Z

Operating system

macOS

Operating system version

12.5.1

Additional context

No response

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the nightly build
• My report contains all necessary details

[ObviousInRetrospect]

also worth noting, this is a regression from 1.8.19 which behaves correctly in the above scenario.

[per1234]

Hi @ObviousInRetrospect . Thanks for taking the time to submit an issue.

I see we have another report about this at #1685.

It is best to have only a single issue per subject so we can consolidate all relevant discussion to one place, so I'll go ahead and close this in favor of the other.

Please see that issue for the correct way to make the manual installation of megaTinyCore. TL;DR:

git clone https://github.com/SpenceKonde/megaTinyCore.git megaTinyCore-dev

If you end up with additional information to share, feel free to comment in the other thread.

[ObviousInRetrospect]

I actually read through the initial report for that bug and concluded they were related but not the same - that was a complaint about the precedence while in my case the UI claims the precedence is correct but the compiler invocation is wrong.

I tried that manual install method. It didn't change the behavior. The compile error still shows it is using libraries from the board manager core despite claiming in the IDE it is the sketchbook one. I actually think it uses the correct core just not the libraries