RFR (preliminary): JDK-8056999 Make hotspot builds less verbose on default log level

[David Holmes]

Okay - thumbs up!

Thanks,
David

On 5/09/2014 7:53 PM, Magnus Ihse Bursie wrote:
> On 2014-09-04 06:35, David Holmes wrote:
>> Hi Magnus,
>>
>> On 1/09/2014 10:11 PM, Magnus Ihse Bursie wrote:
>>> Even in the default log level ("warn"), hotspots builds are extremely
>>> verbose. With the new jigsaw build system, hotspot is build in parallel
>>> with the jdk, and the sheer amount of hotspot output makes the jdk
>>> output practically disappear.
>>>
>>> This fix will make the following changes:
>>> * When hotspot is build from the top dir with the default log level, all
>>> repetetive and purely informative output is hidden (e.g. names of files
>>> compiled, and the "INFO:" blobs).
>>
>> I think I probably want a default log level a little more informative
>> than that - I like to see visible progress indicators. :)
>>
>>> * When hotspot is build from the top dir, with any other log level
>>> (info, debug, trace), all output will be there, as before.
>>
>> Would be nice to have fixed the excessive/repetitive INFO blocks re
>> FDS :) but that requires more than just controlling an on/off switch.
>>
>>> * When hotspot is build from the hotspot repo, all output will be there,
>>> as before.
>>>
>>> Note! This is a preliminary review -- I have made the necessary changes
>>> for Linux only. If this fix gets thumbs up, I'll continue and apply the
>>> same pattern to the rest of the platforms. But I didn't want to do all
>>> that duplication until I felt certain that I wouldn't have to change
>>> something major. The changes themselves are mostly trivial, but they are
>>> all over the place :-(.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056999
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8056999-less-verbose-hotspot-builds/webrev.01
>>>
>>
>> Seems to be some overlap with the $(QUIETLY) mechanism - but to be
>> honest I always have trouble remembering how that works. In looking at
>> it now it seems to me that "$(QUIETLY) echo" is incorrect as the text
>> is always echoed, what gets suppressed is the echoing of the echo
>> command itself - which seems pointless. So I think all "$(QUIETLY)
>> echo" should just be @echo.
>
> I believed that QUIETLY was either set to empty or to @ (default), to
> supress output of the actual command. And yes, ever seeing the actual
> echo command as well as the output seems pointless, so it could probably
> have been @ instead.
>
> But there is no overlap there with my fix. The QUIETLY / @ only handles
> whether the echo command itself is written by make before it is
> executed. The output is always written anyway, and that is what my fix
> deals with.
>
>
>>
>> But then replacing @echo with a $(ECHO) that may be silent would seem
>> a bit cleaner that "@echo $(LOG_INFO). (Not sure what you are doing in
>> the rest of the build).
>
> So what I am doing here is applying the same pattern as we have in the
> rest of build-infra. There we have a group of macros (LOG_WARN,
> LOG_INFO, LOG_DEBUG and LOG_TRACE). The evaluate to either empty, or to
> " > /dev/null". This means that you can determine the log level you want
> this particular output to be on, and it's fairly readable what the
> intention is. E.g.:
> $(ECHO) $(LOG_DEBUG) Starting clusterfrizz process now
>
> It is non-trivial to export these to hospot, so I only copied the
> definition of the one I care about for now, LOG_INFO.
>
> I don't think it's a good idea to change $ECHO, since it is used like this
> $(ECHO) # Generated file, do not edit! > tmp/myfile.h
>
> You *could* introduce a new $(ECHO_LOG_INFO) or so, but I don't think
> it's better. A valuable effect of the build-infra pattern is that it can
> be applied to any command (such as build tools), not just echo.
>
>>
>> print_info is nice.
>
> Thanks.
>
> /Magnus