GNOME Bugzilla – Bug 580062
Support AM_SILENT_RULES
Last modified: 2014-05-02 15:53:12 UTC
http://git.lespiau.name/cgit/shave/tree/README shave is quite cool to clean the build output so you actually see what's going on instead of some random junk. It'd be nice to have gnome-common integrate this so all gnome modules can benefit from this.
automake1.11 has a feature that sounds the same. IMO would be better to "require newer version of existing tool" than to drag in a new special-purpose widget. The known-bugs listed in that README seem to introduce lots of possible breakage and work-arounds in externally-supplied components.
Related bug: http://bugzilla.gnome.org/show_bug.cgi?id=582955
Hello Daniel, I agree with you. It'd be great if you add here: http://live.gnome.org/GnomeGoals/NicerBuilds how do this with the new automake version
I don't have a live.gnome account (login page doesn't have a link for signing up), but the way is really trivial: in configure.{in,ac}, either add AM_SILENT_RULES or add silent-rules as an option to AM_INIT_AUTOMAKE. Also adjust autogen.sh to require automake>=1.11. The default build behavior is "same as previous" (i.e., verbose), but now user can choose quiet by "./configure --enable-silent-rules" or "make V=0". Alternately, AM_SILENT_RULES([yes]) makes quiet the default (same default as shave), and user can "./configure --disable-silent-rules" or "make V=1" to override.
I don't think a hard dependency on automake 1.11 is acceptable. However m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES]) should work here and still be compatible with earlier automake versions.
I updated http://live.gnome.org/GnomeGoals/NicerBuilds to suggest use automake instead shave. Thank you Daniel, Christian!
Support for automake 1.11 already added to gnome-common: http://git.gnome.org/cgit/gnome-common/commit/?id=d0902887d6dac40dcc79f002a4bed2b492ad15d0
So how about setting AM_SILENT_RULES by default in gnome-common?
Well, we could do that, put AM_SILENT_RULES([no]) in e.g. GNOME_COMMONT_INIT. But what happens if the module's configure.ac uses the "silent-rules" automake option in AM_INIT_AUTOMAKE; does our "no" default win, or their option? I think it's the "no" that'll win, since you shouldn't call GNOME_COMMON_INIT before AM_INIT_AUTOMAKE. And if they call AM_SILENT_RULES([yes]), they have to be aware to call it after GNOME_COMMON_INIT... so why not just have the modules handle this themselves?
What about something like: if test "x$AM_DEFAULT_VERBOSITY" = "x"; then m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([no])]) fi (I would put yes as default, but it's just me ;-))
+1 for yes as default; because the vast majority of the modules that already use AM_SILENT_RULES have set yes by default. See http://live.gnome.org/GnomeGoals/NicerBuilds
Other people disagree with "yes" by default too, e.g. mclasen in bug 588863. This also needs changes to intltool [https://bugs.launchpad.net/intltool/+bug/402516] and gnome-doc-utils [bug 589278].
And gtk-doc support [bug 590927].
(In reply to comment #12) > Other people disagree with "yes" by default too, e.g. mclasen in bug 588863. Hello Christian, as far I know, only Glib and GTK+ uses "no" by default; so IMHO I think the common agreemment is yes by default. Anyway, Glib and GTK don't use gnome-common so no problems there.
I think that all projects which want to use silent rules have directly used the upstream macro by now. I do not really think tha tthere is a need for this to be in GNOME common any more.