[erlang-patches] Implement ./otp_build configure --enable-silent-rules

[Anthony Ramine]

Le 28 nov. 2012 à 17:31, Jachym Holecek a écrit :

> # Tuncer Ayaz 2012-11-28:
>> On Wed, Nov 28, 2012 at 3:39 PM, Anthony Ramine wrote:
>>> I got bored of the too verbose output of the build process,
> 
> The output isn't there to amuse you but to give you information for
> troubleshooting in case things go wrong. ;-)

I never said I did this patch to have a fancy output or to be amused by it.

In my quest to EEP20: Split the atoms [1], I need to update a lot of files without ever messing with the Makefiles nor adding any file to the build process or even to the Git repository. Should I be bothered by obscure GCC flags that don't concern me while doing so? Should I not be able to view the various warnings caused by my changes with just a glance? I could use GCC's -Werror but what should I do about warnings that are independent of my tinkering?

>>> so I added automake's silent rules to Erlang/OTP.
> 
> I never understood the point of a build process generating incomplete
> progress report. Either I wan't all the details (almost always) or
> just the final outcome -- something you can do without any patching:
> 
>  $ if ! make > /tmp/build.log 2>&1 ;then echo "BUILD FAILED!!!" ; fi

I could just do make "2>&1 | tee make.log" but it is still a pain to find the relevant warnings in the produced make.log file.

>>> Here is an example of output produced with silent rules:
>>> https://gist.github.com/4160201
>>> 
>>> I may have missed some build tools' invocations as I can only compile
>>> Erlang on my Mac.
>>> 
>>> https://github.com/nox/otp/compare/erlang:master...enable-silent-rules
>>> https://github.com/nox/otp/compare/erlang:master...enable-silent-rules.patch
>>> 
>>> git fetch https://github.com/nox/otp enable-silent-rules
>> 
>> Nice patch, but I would prefer to make the default be silent.
> 
> That's actively harmful -- a build failing on you with useless output
> is already bad enough, having to re-run the build is annoying on its
> own, having to additionally figure out the option that will give you
> useful output is almost insulting.


I'm with you on letting it non-default; I sometimes yell at rebar for this very reason when I want to see its erlc invocations.

[1] You can follow my progress on this on https://github.com/nox/otp/compare/erlang:master...eep20

-- 
Anthony Ramine