[RFC] make output of compiling a bit less verbose to make warnings more visible

[RFC] make output of compiling a bit less verbose to make warnings more visible

[Felix Zielcke]

Hello,

I think it would be good if the output from compiling wouldn't be that
verbose.
Just like on compiling the Linux kernel.
It shows only something like:

CC source.c
LD built-in.o
VDSO-SYM? bla

instead of that whole `gcc -D GRUB_UTIL -o xx x.c ...' thing.

I haven't bothered to check yet how complicated it would be to implement
this but I think it would be better to ask first if you even like this
idea :)

-- 
Felix Zielcke

Re: [RFC] make output of compiling a bit less verbose to make warnings more visible

[Felix Zielcke]

Am Dienstag, den 02.09.2008, 18:43 +0200 schrieb Felix Zielcke:
> Hello,
> 
> I think it would be good if the output from compiling wouldn't be that
> verbose.

Urm thanks again to Vesa who remembered that Colin brought that topic
originally up here.

http://lists.gnu.org/archive/html/grub-devel/2008-06/msg00248.html

I really would love to have this somehow commited :)

-- 
Felix Zielcke

Re: [RFC] make output of compiling a bit less verbose to make warnings more visible

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

El mar, 02-09-2008 a las 18:43 +0200, Felix Zielcke escribió:
> Hello,
> 
> I think it would be good if the output from compiling wouldn't be that
> verbose.
> Just like on compiling the Linux kernel.
> It shows only something like:
> 
> CC source.c
> LD built-in.o
> VDSO-SYM? bla
> 
> instead of that whole `gcc -D GRUB_UTIL -o xx x.c ...' thing.
> 
> I haven't bothered to check yet how complicated it would be to implement
> this but I think it would be better to ask first if you even like this
> idea :)
> 
This was discussed earlier; some people argued about warnings and such,
and the OP said this would make warnings stand out _more_, not less.
After some more posts that I don't really remember the discussion died.
the link to the full thread is at [0].

I tried to implement the proposal myself, but modifying the Ruby file
that creates the *.mk files from the *.rmk files proved to be a royal
PITA. I recall I proposed a switch over to a more common tool as Python
and... western-rolling-ball-crossing-the-street. Feel free to try!

-Habbit

[0] http://lists.gnu.org/archive/html/grub-devel/2008-06/msg00248.html

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [RFC] make output of compiling a bit less verbose to make warnings more visible

[Robert Millan]

On Tue, Sep 02, 2008 at 07:10:05PM +0200, Felix Zielcke wrote:
> Am Dienstag, den 02.09.2008, 18:43 +0200 schrieb Felix Zielcke:
> > Hello,
> > 
> > I think it would be good if the output from compiling wouldn't be that
> > verbose.
> 
> Urm thanks again to Vesa who remembered that Colin brought that topic
> originally up here.
> 
> http://lists.gnu.org/archive/html/grub-devel/2008-06/msg00248.html
> 
> I really would love to have this somehow commited :)

I don't remember that discussion well;  ISTR I complained.  Maybe that
stopped it?  Anyway, as long as it's user-selectable it's not a problem
for me.  Maybe I even end up using it ;-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] make output of compiling a bit less verbose to make warnings more visible

[Vesa Jääskeläinen]

Robert Millan wrote:
> On Tue, Sep 02, 2008 at 07:10:05PM +0200, Felix Zielcke wrote:
>> Am Dienstag, den 02.09.2008, 18:43 +0200 schrieb Felix Zielcke:
>>> Hello,
>>>
>>> I think it would be good if the output from compiling wouldn't be that
>>> verbose.
>> Urm thanks again to Vesa who remembered that Colin brought that topic
>> originally up here.
>>
>> http://lists.gnu.org/archive/html/grub-devel/2008-06/msg00248.html
>>
>> I really would love to have this somehow commited :)
> 
> I don't remember that discussion well;  ISTR I complained.  Maybe that
> stopped it?  Anyway, as long as it's user-selectable it's not a problem
> for me.  Maybe I even end up using it ;-)

I think the strength was that you could provide V=99 (or something like
that to give previous behavior ("debug feature").

So basically that is completed.

Only thing perhaps would need attention is to show that now we compile
for HOST CC and now for TARGET CC or so.

Re: [RFC] make output of compiling a bit less verbose to make warnings more visible

[Colin D Bennett]

On Tue, 02 Sep 2008 22:43:54 +0300
Vesa Jääskeläinen <chaac@nic.fi> wrote:

> Robert Millan wrote:
> > On Tue, Sep 02, 2008 at 07:10:05PM +0200, Felix Zielcke wrote:
> >> Am Dienstag, den 02.09.2008, 18:43 +0200 schrieb Felix Zielcke:
> >>> Hello,
> >>>
> >>> I think it would be good if the output from compiling wouldn't be
> >>> that verbose.
> >> Urm thanks again to Vesa who remembered that Colin brought that
> >> topic originally up here.
> >>
> >> http://lists.gnu.org/archive/html/grub-devel/2008-06/msg00248.html
> >>
> >> I really would love to have this somehow commited :)
> > 
> > I don't remember that discussion well;  ISTR I complained.  Maybe
> > that stopped it?  Anyway, as long as it's user-selectable it's not
> > a problem for me.  Maybe I even end up using it ;-)
> 
> I think the strength was that you could provide V=99 (or something
> like that to give previous behavior ("debug feature").

In my 'pretty make' patch, setting V=1 (verbose on) restores original
full command output.

> So basically that is completed.
> 
> Only thing perhaps would need attention is to show that now we compile
> for HOST CC and now for TARGET CC or so.

Also, it was suggested that new variables (like CC, STRIP, etc.) be
introduced an instead of overriding the existing variables, which my
patch currently does as follows (this is 90% of the patch
functionality):

### Pretty output control ###
# Set up compiler and linker commands that either is quiet (does not
print # the command line being executed) or verbose (print the command
line). 
_CC := $(CC)
_TARGET_CC := $(TARGET_CC)
_STRIP := $(STRIP)
_GENMODSRC := sh $(srcdir)/genmodsrc.sh
ifeq ($(V),1)
 override V_PREFIX :=
 override CC = $(_CC)
 override TARGET_CC = $(_CC)
 override STRIP = $(_STRIP)
 override GENMODSRC = $(_GENMODSRC)
 override INFO_GENCMDLIST =
 override INFO_GENFSLIST =
 override INFO_GENPARTMAPLIST =
 override INFO_GEN_FINAL_COMMAND_LIST =
 override INFO_GEN_FINAL_FS_LIST =
 override INFO_GEN_FINAL_PARTMAP_LIST =
else
 override V_PREFIX := @
 override CC = @echo "COMPILE         $<"; $(_CC)
 override TARGET_CC = @echo "COMPILE(TARGET) $<"; $(_TARGET_CC)
 override STRIP = @echo "STRIP           $@"; $(_STRIP)
 override GENMODSRC = @echo "GENMODSRC       $@"; $(_GENMODSRC)
 override INFO_GENCMDLIST = @echo "GENCMDLIST      $@"
 override INFO_GENFSLIST = @echo "GENFSLIST       $@"
 override INFO_GENPARTMAPLIST = @echo "GENPARTMAPLIST  $@"
 override INFO_GEN_FINAL_COMMAND_LIST = @echo "GENCMDLIST[final]  $@"
 override INFO_GEN_FINAL_FS_LIST = @echo "GENFSLIST[final]   $@"
 override INFO_GEN_FINAL_PARTMAP_LIST = @echo "GENPARTMAPLIST[final]
$@" endif


I have held off on doing this with all new variables, because it would
mean changing *every* reference to the toolchain variables.  I found
that by simply overriding them, it was really nonintrusive, in
general.  However, there were developers that objected to the
overriding.

Regards,
Colin

Re: [RFC] make output of compiling a bit less verbose to make warnings more visible

[Felix Zielcke]

Am Dienstag, den 02.09.2008, 13:47 -0700 schrieb Colin D Bennett:
> On Tue, 02 Sep 2008 22:43:54 +0300
> Vesa Jääskeläinen <chaac@nic.fi> wrote:
> 
> > Robert Millan wrote:
> > > I don't remember that discussion well;  ISTR I complained.  Maybe
> > > that stopped it?  Anyway, as long as it's user-selectable it's not
> > > a problem for me.  Maybe I even end up using it ;-)

This only needs to be the default then you Robert will end up using
it ;)

> I have held off on doing this with all new variables, because it would
> mean changing *every* reference to the toolchain variables.  I found
> that by simply overriding them, it was really nonintrusive, in
> general.  However, there were developers that objected to the
> overriding.
> 

Honourly I'm exactly your opion.
The linux primary kernel Makefile clearly says how it works, I haven't
bothered to check the other files how exactly they implemented it. I
doubt that it would help me.

For grub2 these overrides seems to be the best solution as long as
nobody is willing/able to rewrite the whole build system.

There exists even a thing called `GNU automake' which converts
Makefile.am files to Makefile.in
I never used it though, so I don't really know if it would be easier
with it then in that ruby stuff currently used.

I'd really love to have this, but if these overrides are not acceptable
then I doubt we will have it ever.
I would need ages to find out how to do it with that ruby stuff or even
how to rewrite the whole build system :(
I myself wrote only some small little Makefiles not Makefile.am not
Makefile.in but a final small Makefile.

-- 
Felix Zielcke

Re: [RFC] make output of compiling a bit less verbose to make warnings more visible

[Hans Lambermont]

Felix Zielcke wrote on 20080902:

> I think it would be good if the output from compiling wouldn't be that
> verbose.

* shameless plug mode on *

Maybe my hmake wrapper for gnu make does what you want : A make and
cc/c++ output (color)filter written in perl. Especially useful if your
warning level is so high that the compiler starts to complain about your
system header files.  See http://lambermont.dyndns.org/hmake

* shameless plug mode off *

regards,
    Hans Lambermont
-- 
Hans Lambermont, M.Sc.  -  Newtec  -  OS-Platform&VAS
http://newtec.eu/    t:+31408519234    m:+31629064887

Re: [RFC] make output of compiling a bit less verbose to make warnings more visible

[Bean]

On Wed, Sep 3, 2008 at 2:59 PM, Felix Zielcke <fzielcke@z-51.de> wrote:
> There exists even a thing called `GNU automake' which converts
> Makefile.am files to Makefile.in
> I never used it though, so I don't really know if it would be easier
> with it then in that ruby stuff currently used.
>
> I'd really love to have this, but if these overrides are not acceptable
> then I doubt we will have it ever.
> I would need ages to find out how to do it with that ruby stuff or even
> how to rewrite the whole build system :(
> I myself wrote only some small little Makefiles not Makefile.am not
> Makefile.in but a final small Makefile.

Hi,

I think automake can't do the job. The grub2 build process is
complicated. For example, it needs to go through all the object files
to generate the module dependence trunk, and append it to *.o to form
the final *.mod. I believe it's very tricky to write a automake script
to handle this.

However, I don't like that it uses ruby to generate makefiles. Ruby is
not a standard component, so there is a chance that user don't install
it. I guess perl would be better.

-- 
Bean

Re: [RFC] make output of compiling a bit less verbose to make warnings more visible

[Felix Zielcke]

Am Mittwoch, den 03.09.2008, 16:37 +0800 schrieb Bean:

> However, I don't like that it uses ruby to generate makefiles. Ruby is
> not a standard component, so there is a chance that user don't install
> it. I guess perl would be better.

I had somehow already the impression that this ruby based build system
isn't really well maintained ;)
I looked now even a bit over the automake[0] documentation.

For me personally it just looks easier to get into that, because it is
just made for Makefile's instead of some perl/python/ruby script which
generates them.

If automake isn't enough maybe we could use a combination of it with a
small perl script or so?
Though I don't know any perl/python/ruby at all.

I'm willing to really look into this automake stuff if there are no
strong objections against it, in the hope that in the end the build
system is clean, easily understandable and can be well maintained :)

Though this will probable take a little while so I still think Colin's
way would be a good short term solution and for long term we remake the
whole build process with that idea integrated from the beginning.

[0] http://www.gnu.org/software/automake/manual/automake.html

-- 
Felix Zielcke