Duplicate library message missing in non-verbose mode

[PaulStoffregen]

The "Multiple libraries were found for" message is no longer appearing when verbose info during compilation is turned off. It used to print in Arduino 1.6.9, but disappeared in 1.6.10 and hasn't been printing in non-verbose mode since.

Please consider restoring the printing of this important info in non-verbose mode. This duplicate library message is critically important for resolving problems users encounter when they try to install libraries and unknowingly create conflicts.

However, one case should not cause this message to print (and current is doing so in verbose mode), when a library provided by a platform package overrides one of the built-in library. This is normal, where platform packages like ChipKit, Teensy, Intel arc32 (Arduino 101) and others provide their own versions of Servo and other libs customized to the hardware on those other platforms. Especially in non-verbose mode, it's important to print "Multiple libraries were found for" only in the cases where a conflict is not normal and should be brought to the user's attention.

[PaulStoffregen]

I see it is printing the message when a compile error occurs. But if the compile succeeds, the user gets no indication the IDE had to choose between 2 different libraries with both matched their sketch.

[matthijskooijman]

This change was intentional, see #151, since deciding when the overriding was "intentional" and the message should be hidden is a very non-trivial problem (and the previous approach had false positives, see the PR), so the reasoning was that if it compiles properly, things are probably as intended.

[PaulStoffregen]

I'm seeing a resurgence of novice user questions & problems which are ultimately due to an incompatible copy of a library in their sketchbook folder, which compiles without error, but then doesn't work because it lacks extra hardware support needed for a specific architecture.

Even though this change was intentional, and for a fairly logical reason, in practice this change is really hurting me and quite likely other 3rd party board makers.

Is there any chance I could talk you into considering at least an optional setting (from boards.txt or platform.txt) to show the duplicate libraries message in non-verbose mode? The case where sketchbook library overrides a platform-provided library is the main problem, so perhaps just showing it for that case would be enough. I'm answering this question again on a semi-regular basis, and real people are suffering these difficult-to-diagnose problems when the incompatible libraries do compile without error, but of course don't work because they're designed for different hardware.

[cmaglie]

@matthijskooijman
On #151 we used your rules:

• Sketch fails to compile -> emit message as warning, in red
• Verbose compilation enabled -> emit message as informational, in white

as per @PaulStoffregen request it will be

• Sketch fails to compile -> emit message as warning, in red
• If sketchbook lib override core lib -> emit message as informational, in white
• Verbose compilation enabled -> emit message as informational, in white

but thinking on it again IMHO it won't hurt to just show the message every time in white, so:

• Sketch fails to compile -> emit message as warning, in red
• always -> emit message as informational, in white

[PaulStoffregen]

Yes, that sounds good. :) Printing in less-alarming white text is good.

But one case that probably should not emit the message in non-verbose mode is a core lib overriding a builtin lib. For example, nearly all core libs for other architectures need to override Servo, which has AVR, SAM & SAMD timers hard-coded. These cases are normal, expected overrides that shouldn't pester users.

[matthijskooijman]

But one case that probably should not emit the message in non-verbose mode is a core lib overriding a builtin lib.

I'm not convinced that:

• this is indeed exactly the exception that is needed
• such an exception is always helpful rather than harmful.

However, I do not have a very strong preference here. IIRC the reason I changed it was mostly because I was cleaning up the library resolution code a bit and this code stood out as a somewhat vaguely-defined exception, and someone reported a problem around the same time.

Looking more closely at what @cmaglie wrote, that does indeed seem like a sensible approach (and it's easy to implement too (just remove the if on this line I think).