libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ltmain.in: don't suppress output for PIC compilations


From: Sam James
Subject: Re: [PATCH] ltmain.in: don't suppress output for PIC compilations
Date: Sat, 17 Aug 2024 08:00:23 +0100

Roumen Petrov <bugtrack@roumenpetrov.info> writes:

> Hello,
>
> На 15.08.24 г. в 21:27 ч., Nick Bowler написа:
>> On 2024-08-15 14:13, Ileana Dumitrescu wrote:
>>> Printing the differences on the second run seems like a better default,
>>> while keeping the option for -no-suppress for the complete log. Maybe
>>> adding an informational message about -no-suppress with the diff
>>> would help resolve some confusion?
>
> Similar topic was discussed already.
> Failure in static build are exceptional.
> Shared and static build should produce one and the same result.
> Note that you could disable shared build and in this case result or
> static build is displayed!
>
> I prefer do not see double output in build process i.e. is in past decades.
>
>

I think you're agreeing with Nick? i.e. you'd be okay with possibly some
automatic diffing, but not showing the full output unconditionally?

>>> However, I also wonder if the suppression should be decided by a
>>> verbosity option/variable rather than a compile mode option.
>> Yes, I was a bit surprised to discover that the existing --verbose
>> flag which is documented in the manual to
>>    "Print out ... additional messages not ordinary seen by default"
>> does not disable this suppression.  If it did, then presumably
>> automated
>> build robots (at least when it comes to Automake-generated packages)
>> could just build with make LIBTOOLFLAGS=--verbose and be done.
>
>
> Models static vs shared build are not related to build process trace.
> Why to output static build as in 99.9999999% cases is same as shared?
>

In many cases, you won't get any warnings at all, so you're not doubling
up anything.

I still argue it's against the principle of least surprise and in
general not particularly right for a tool to suppress errors based on
probability and a value judgement like this.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]