Slick build output

[Jason But]

Hello all,

Not really related to the actual wine development but more to the 
make/build/install environment.

Remembering the most wine users will not necessarily be developers we should 
consider improving the output of running (./configure && make) to make it 
more user friendly.  Hopefully it should also be less confronting and 
confusing to non developers.  I propose something similar to the way the 
Linux kernel currently compiles.  The included patch changes make so that a 
regular make will produce much nicer output while for those die-hards who 
prefer the original output this can be achieved by executing

make VERBOSE=yes

I personally prefer the neater output even for development work, the compile 
output doesn't scroll off the screen as quickly and warnings/errors can be 
more easily spotted.

This patch doesn't do the complete job, instead only produces output for the 
compile (gcc) stages.  In fact, (make install) will produce no output at all!  
If people think this is a good idea, simple extensions will lead to complete 
output, just add the necessary

$(NICE_ECHO) "    whatever"

to the proper places in each Make*.in file

I am willing to do this if it is deemed to be good.

Jason

[Robert Shearman]

Jason But wrote:
> Hello all,
>
> Not really related to the actual wine development but more to the 
> make/build/install environment.
>
> Remembering the most wine users will not necessarily be developers we should 
> consider improving the output of running (./configure && make) to make it 
> more user friendly.  Hopefully it should also be less confronting and 
> confusing to non developers.  I propose something similar to the way the 
> Linux kernel currently compiles.  The included patch changes make so that a 
> regular make will produce much nicer output while for those die-hards who 
> prefer the original output this can be achieved by executing
>
> make VERBOSE=yes
>
> I personally prefer the neater output even for development work, the compile 
> output doesn't scroll off the screen as quickly and warnings/errors can be 
> more easily spotted.
>
> This patch doesn't do the complete job, instead only produces output for the 
> compile (gcc) stages.  In fact, (make install) will produce no output at all!  
> If people think this is a good idea, simple extensions will lead to complete 
> output, just add the necessary
>
> $(NICE_ECHO) "    whatever"
>
> to the proper places in each Make*.in file
>
> I am willing to do this if it is deemed to be good.

I think this would be really good for the reasons you have already 
stated. Though, you don't seem to have included the patch that you refer 
to above. Please continue your work on this!

Thanks,
Rob

[Alexandre Julliard]

Jason But  writes:
> Not really related to the actual wine development but more to the 
> make/build/install environment.
>
> Remembering the most wine users will not necessarily be developers we should 
> consider improving the output of running (./configure && make) to make it 
> more user friendly.  Hopefully it should also be less confronting and 
> confusing to non developers.

I think it's a lot more important to make it useful for developers,
which is what it is now. Users who get intimidated by the make output
should use a binary package.

[Robert Shearman]

Alexandre Julliard wrote:
> Jason But  writes:
> > Not really related to the actual wine development but more to the 
> > make/build/install environment.
> >
> > Remembering the most wine users will not necessarily be developers we should 
> > consider improving the output of running (./configure && make) to make it 
> > more user friendly.  Hopefully it should also be less confronting and 
> > confusing to non developers.
>
> I think it's a lot more important to make it useful for developers,
> which is what it is now.

How many developers need to see the command line being passed to gcc? I 
would argue that it would be more useful if there was a short "[CC] 
regsvr.c" rather than the multi-line output there is now which makes 
warnings more difficult to spot.

Rob

[Dmitry Timoshkov]

"Robert Shearman"  wrote:
> How many developers need to see the command line being passed to gcc? I 
> would argue that it would be more useful if there was a short "[CC] 
> regsvr.c" rather than the multi-line output there is now which makes 
> warnings more difficult to spot.

It's always helpful to see full command lines especially after configure
or makefile changes. Personally I usually do 'make 2>build.log' if I want
to see warnings or errors.

[Robert Shearman]

Dmitry Timoshkov wrote:
> "Robert Shearman"  wrote:
> > How many developers need to see the command line being passed to gcc? I 
> > would argue that it would be more useful if there was a short "[CC] 
> > regsvr.c" rather than the multi-line output there is now which makes 
> > warnings more difficult to spot.
>
> It's always helpful to see full command lines especially after configure
> or makefile changes.

I haven't had any need for that, but on the rare occasion that you might 
need that there is "make VERBOSE=yes".
> Personally I usually do 'make 2>build.log' if I want
> to see warnings or errors.

write_msft.c:590: warning: 'ctl2_alloc_importinfo' defined but not used
write_msft.c:628: warning: 'ctl2_alloc_importfile' defined but not used
write_msft.c:1048: warning: 'ctl2_find_nth_reference' defined but not used

It doesn't give the path, so that approach is useless except when 
building one directory on its own.

Rob

[Vincent Béron]

Le ven 28/01/2005 à 12:22, Robert Shearman a écrit :
[snip]
> write_msft.c:590: warning: 'ctl2_alloc_importinfo' defined but not used
> write_msft.c:628: warning: 'ctl2_alloc_importfile' defined but not used
> write_msft.c:1048: warning: 'ctl2_find_nth_reference' defined but not used
>
> It doesn't give the path, so that approach is useless except when 
> building one directory on its own.

It's not like there are 10 write_msft.c files in the Wine source, so
it's not useless. Even if find finds multiple instances of a similarly
named file, it's usually pretty easy to find the originating file of a
warning.

Vincent

[Robert Shearman]

Vincent Béron wrote:
> Le ven 28/01/2005 à 12:22, Robert Shearman a écrit :
> [snip]
> > write_msft.c:590: warning: 'ctl2_alloc_importinfo' defined but not used
> > write_msft.c:628: warning: 'ctl2_alloc_importfile' defined but not used
> > write_msft.c:1048: warning: 'ctl2_find_nth_reference' defined but not used
> >
> > It doesn't give the path, so that approach is useless except when 
> > building one directory on its own.
>
> It's not like there are 10 write_msft.c files in the Wine source, so
> it's not useless.

I was going to do an example with regsvr.c, but I thought people would 
get the point.
> Even if find finds multiple instances of a similarly
> named file, it's usually pretty easy to find the originating file of a
> warning.

I prefer to leave the gambling at the casino.

Rob

[Marcus Meissner]

On Fri, Jan 28, 2005 at 06:03:20PM -0600, Robert Shearman wrote:
> Vincent Béron wrote:
> > Le ven 28/01/2005 à 12:22, Robert Shearman a écrit :
> > [snip]
> > > write_msft.c:590: warning: 'ctl2_alloc_importinfo' defined but not used
> > > write_msft.c:628: warning: 'ctl2_alloc_importfile' defined but not used
> > > write_msft.c:1048: warning: 'ctl2_find_nth_reference' defined but not used
> > >
> > > It doesn't give the path, so that approach is useless except when 
> > > building one directory on its own.
> >
> > It's not like there are 10 write_msft.c files in the Wine source, so
> > it's not useless.
>
> I was going to do an example with regsvr.c, but I thought people would 
> get the point.

The developer can use "make -s" if he wants to see less.

vis and emacs automatic errorline jump will also stop working.

Ciao, Marcus

[Mike Hearn]

On Fri, 28 Jan 2005 18:42:08 -0500, Vincent Béron wrote:
> It's not like there are 10 write_msft.c files in the Wine source

No, but am I the only one who gets annoyed at how many thread.c
files there are? I'm sure everyone can think of their pet example, but
there are a lot of files in the Wine tree that are related yet different,
but use the same names.

I'll try the patch though, the huge spew that the build system outputs
does get annoying ...

thanks -mike

[Steven Edwards]

Hi Jason,

--- Jason But  wrote:
> This patch doesn't do the complete job, instead only produces output for the 
> compile (gcc) stages.  In fact, (make install) will produce no output at all!  
> If people think this is a good idea, simple extensions will lead to complete 
> output, just add the necessary
>
> $(NICE_ECHO) "    whatever"
>
> to the proper places in each Make*.in file
>
> I am willing to do this if it is deemed to be good.

I for one like the quite output during builds that the kernel has. Send a patch...maybe julliard
will accept it.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250