From: Christophe F. <te...@gn...> - 2009-05-27 19:38:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've recently experimented with adding shave [0] support to make libgpod compilation output more readable: $ make -j3 Making all in src CC itdb_itunesdb.o CC itdb_device.o LINK libgpod.la Before committing it, I wanted to know if there was any objection? (you can get the verbose output by disabling shave at configure time) I'll commit it next week if nobody complains :) Cheers, Christophe [0] http://damien.lespiau.name/blog/2009/02/18/shave-making-the-autotools-output-sane/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkodlnUACgkQJKRp+3pW947ywQCdGPn7/D7tJ2AeVhgHpNwtmgXc ufwAoIiOiil3CnG2lChQco4S19e8pGHX =Qjd4 -----END PGP SIGNATURE----- |
From: Todd Z. <tm...@po...> - 2009-05-27 20:23:21
|
Christophe Fergeau wrote: > I've recently experimented with adding shave [0] support to make > libgpod compilation output more readable: > > $ make -j3 > Making all in src > CC itdb_itunesdb.o > CC itdb_device.o > LINK libgpod.la Amusingly, I noticed in the automake-1.11 announcement¹ just last week: "Optional Linux kernel style less verbose compile rules..." So they've been working on this too. :) > Before committing it, I wanted to know if there was any objection? (you > can get the verbose output by disabling shave at configure time) I see on the shave site that the currently released gtk-doc has a bug that affects shave. It is patched in gtk-doc's svn, but that's unlikely to help most of the people building libgpod on their distro. Would we need to apply the sed work-around mentioned on the shave site? Or doesn't it cause any real problem for libgpod? I couldn't tell what might be wrong while testing your shave branch. Testing your shave branch, I had to scratch my head over this output: Making all in python ../../src/itdb.h:264: Warning(451): Setting a const char * variable may leak memory. ../../src/itdb.h:264: Warning(451): Setting a const char * variable may leak memory. Making all in examples Making all in tests CC gpod_wrap.o LINK _gpod.la I thought the ordering was odd, because I missed that it wasn't in tests, but in bindings/python/tests. (And while we're here, if anyone knows swig well enough to know whether that Warning is really something to worry about, I'd love to see it get fixed or silenced. I've not silenced it so far since I'm not sure it it's something that needs fixing or not.) > I'll commit it next week if nobody complains :) We'll just wait a week and complain anyway. ;) I've yet to try automake-1.11 to see how the output compares to shave, but perhaps once automake-1.11 is available in common distros we can switch to that? (But that will be a while. :) It does fix one minor thing I have queued up here too, replacing the use of AC_OUTPUT with arguments (deprecated since autoconf-2.50, circa 2001). I've got a few other minor cleanups to the autoconf/automake rules in configure.ac that I'll try to get around to pushing sometime soon. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Though you take no interest in politics, politics, alas, takes an interest in you. -- Pericles |
From: Christophe F. <te...@gn...> - 2009-05-27 20:54:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Todd Zullinger a écrit : > Amusingly, I noticed in the automake-1.11 announcement¹ just last week: > > "Optional Linux kernel style less verbose compile rules..." Yeah, maybe the guy who made shave managed to push it upstream :) > I see on the shave site that the currently released gtk-doc has a bug > that affects shave. It is patched in gtk-doc's svn, but that's > unlikely to help most of the people building libgpod on their distro. > Would we need to apply the sed work-around mentioned on the shave > site? Or doesn't it cause any real problem for libgpod? I couldn't > tell what might be wrong while testing your shave branch. I must say I haven't really paid attention to that. Maybe it just means gtk-doc output isn't fully hidden while shave is active? I'd have to try the small sed patch ;) > > I thought the ordering was odd, because I missed that it wasn't in > tests, but in bindings/python/tests. Hmmm, true. I guess this is something one gets used to. Alternatively, we probably can convince the shave author to change it. > I've yet to try automake-1.11 to see how the output compares to shave, > but perhaps once automake-1.11 is available in common distros we can > switch to that? (But that will be a while. :) > Yep sure :) Though we'll want to keep compat with older automakes for a looooong time imo (I generally try to keep things working with automake 1.7 and later, dunno in which state libgpod is these days) > It does fix one minor thing I have queued up here too, replacing the > use of AC_OUTPUT with arguments (deprecated since autoconf-2.50, circa > 2001). I've got a few other minor cleanups to the autoconf/automake > rules in configure.ac that I'll try to get around to pushing sometime > soon. Yep, feel free to push them any time (if it conflicts with the shave changes, it's no big deal to fix, so don't wait ;) Christophe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEARECAAYFAkodqEsACgkQJKRp+3pW9440MACfasvnQ4DCqeBqmMOMj6EjzhEc /XMAoMam7GRQO8+T3nuyUcF9q8j7/JnR =z9Rd -----END PGP SIGNATURE----- |
From: Christophe F. <te...@gn...> - 2009-06-06 19:54:28
|
Hi, 2009/5/27 Christophe Fergeau <te...@gn...>: > -----BEGIN PGP SIGNED MESSAGE----- > > I must say I haven't really paid attention to that. Maybe it just means > gtk-doc output isn't fully hidden while shave is active? I'd have to try > the small sed patch ;) I just tried it with libtool 1.5, and I couldn't make a difference with/without the patch. No failure in either case, same output as far as I can tell. Christophe |