[erlang-patches] Implement ./otp_build configure --enable-silent-rules
Anthony Ramine
n.oxyde@REDACTED
Fri Jan 11 18:12:44 CET 2013
I could do that, it would make things easier. The patch doesn't yet handle all the things but I
submitted it anyway to have a feedback earlier and to know whether I should bother finishing it.
I guess your answer is positive enough for me to finish it :) I'll do that this weekend.
Regards,
--
Anthony Ramine
Le 11 janv. 2013 à 18:06, Björn-Egil Dahlberg a écrit :
> In review.
>
> This looks nice and the make output looks crisp and clear. Ehum .. apparently warnings is easier to see as well =o
>
> Did you consider doing something like moving the sed rules to make/otp.mk.in instead of changing all the files?
>
> $(APP_TARGET): $(APP_SRC) ../vsn.mk
> $(vsn_verbose)sed -e 's;%VSN%;$(VSN);' $< > $@
>
> $(APPUP_TARGET): $(APPUP_SRC) ../vsn.mk
> $(vsn_verbose)sed -e 's;%VSN%;$(VSN);' $< > $@
>
> I'm not sure if it would be best or if it even works, just like to hear your thoughts on it.
>
> // Björn-Egil
>
>
> On 2012-11-29 10:49, Anthony Ramine wrote:
>> 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
>>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
More information about the erlang-patches
mailing list