[Mesa-dev] [PATCH] automake: make the build less chatty

[Matt Turner]

On Thu, Dec 8, 2016 at 6:55 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 8 December 2016 at 14:07, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> On 08.12.2016 12:30, Emil Velikov wrote:
>>>
>>> On 7 December 2016 at 20:20, Eric Anholt <eric at anholt.net> wrote:
>>>>
>>>> Emil Velikov <emil.l.velikov at gmail.com> writes:
>>>>
>>>>> From: Emil Velikov <emil.velikov at collabora.com>
>>>>>
>>>>> Having the "Entering|Leaving directory X" messages it not required nor
>>>>> useful in vast majority of the cases.
>>>>>
>>>>> One can always have them printed by `make -w' or by overriding the
>>>>> AM_MAKEFLAGS variable.
>>>>>
>>>>> Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
>>>>
>>>>
>>>> I tried this out today and it breaks my go-to-error macro in emacs.  I
>>>> don't see how an IDE could parse the build output any more to implement
>>>> it, either.
>>>>
>>>> I don't think we should land this.
>>>
>>>
>>> Have you tried any of the following
>>> $ make -w
>>> $ make AM_MAKEFLAGS=
>>> or even specify a specific subfolder containing Makefile.am
>>> $ make -C .
>>> $ make -C src
>>>
>>> I'm not familiar with emacs, let alone the particular macro, or I
>>> would have sent you a patch :-)
>>> There are other projects in the wild who use -s, so using the above
>>> will make your environment more robust.
>>
>>
>> I'm all for reducing chattiness, but I'm not happy about this change either.
>>
>> Maybe those other projects ensure that the base directory for warning and
>> error messages stays at the project root?
> Not entirely sure what you mean here. Can you please elaborate ?

He means that those projects probably build all source files without
changing directory (i.e., non-recursively, from the root directory).

The implication is make -s might make sense in non-recursive builds,
but not in recursive builds like ours.

>
> With and w/o the flag the entire warning/error message is the same.
> The only different that I can see between autohell and cmake is that

autohell? Come on. That's like calling Microsoft M$.

> former uses relative paths, while the latter absolute ones.
> Skimming through - nothing obvious comes up on convincing autoconf to
> generate/use the absolute ones.


So the patch makes what amount to a cosmetic change in the best case.
But... we know that it's not actually cosmetic because the information
lost was useful for at least one person's Emacs macro (which sounds
like something I want, tbh).

It's actually useful for someone. We should keep it.