Slick build output
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
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
Jason But <jbut(a)swin.edu.au> 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. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Jason But <jbut(a)swin.edu.au> 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
"Robert Shearman" <rob(a)codeweavers.com> 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. -- Dmitry.
Dmitry Timoshkov wrote:
"Robert Shearman" <rob(a)codeweavers.com> 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
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
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
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
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
Hi Jason, --- Jason But <jbut(a)swin.edu.au> 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
participants (8)
-
Alexandre Julliard -
Dmitry Timoshkov -
Jason But -
Marcus Meissner -
Mike Hearn -
Robert Shearman -
Steven Edwards -
Vincent Béron