GNOME Bugzilla – Bug 768797
Build: Fix silent builds
Last modified: 2016-07-19 09:52:40 UTC
Silent builds were enabled for some time, but did not really work due to the missing 'yes' option in AM_SILENT_RULES. This patch fixes that.
Created attachment 331469 [details] [review] Build: Fix silent builds Silent builds were introduced in commit fa03634b5963af18340258a67063f3a527c4e471 but they were not really enabled. Passing yes to AM_SILENT_RULES fixes this issue. See https://wiki.gnome.org/Initiatives/GnomeGoals/NicerBuilds for more information.
Review of attachment 331469 [details] [review]: ::: configure.ac @@ +28,2 @@ AM_INIT_AUTOMAKE([1.9 -Wno-portability no-dist-gzip dist-xz tar-ustar no-define nostdinc]) +m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) I think we don't have to check if AM_SILENT_RULES macro is defined. AM_SILENT_RULES([yes]) should be sufficient.
Maybe not, but this is currently the applied practice and virtually all other modules that use silent rules also do the check, so I suggest to just keep it at least for the sake of consistency. Besides it does not do any harm.
Marcin, so do you insist on dropping the ifdef guard? Or could my last comment change your mind? Please let me know and I can upload a new patch, so we can close this issue quickly.
I've just opened few random GNOME repositories (glib, gtk+ and gnome-builder) - they all don't have the m4_ifdef. But it's a nitpick, I don't mind having it or not.
Marcin, I took a second look, it seems that from 127 modules that I have currently checked out, 70 have the m4 guard and 57 do not have it. So my original statement was not quite right, but still the majority does use the guard. Anyway as you don't mind I have just pushed the patch as commit b46a1362c5f09ec4244abce814832faacaec3091 Thank you for you comments.
> +m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) I think the idea is to support older versions of auto* that don't define AM_SILENT_RULES. But maybe we require new enough auto* anyway. Well, if something doesn't work for someone, they will let us know. Thanks.
Interesting! I didn't know it's that easy to get less noisy builds. But why fix only glibmm? We have other modules with the same incomplete use of AM_SILENT_RULES. I can fix some of them, such as gtkmm, libsigc++, libxml++ and the template file mm-common/skeletonmm/configure.ac. Does anyone know if there is also an easy way to make doxygen less noisy? It prints an awful lot of uninteresting information when it builds our reference documentation.
@Kjell, a quick google search shows that doxygen has a QUIET option, I just tried that and it significantly reduces the output to only three lines: Making all in docs GEN reference/glibmm-2.4.tag GEN reference/glibmm-2.4.devhelp2 A quick look at some other modules shows that some have turned it on by default: $find . -regex .*Doxyfile|xargs grep QUIET|grep -v \# ./liboauth-1.0.3/Doxyfile:QUIET = YES ./libxkbcommon-0.5.0/doc/Doxyfile:QUIET = YES ./gnutls-2.12.8/doc/doxygen/Doxyfile:QUIET = NO ./freerdp/docs/Doxyfile:QUIET = NO ./metacity/Doxyfile:QUIET = YES ./compiz/Doxyfile:QUIET = NO ./libical-1.0.1/doc/Doxyfile:QUIET = NO ./libnl-3.2.7/doc/Doxyfile:QUIET = YES ./gnutls-3.3.18/doc/doxygen/Doxyfile:QUIET = NO ./libsigc++2/docs/reference/Doxyfile:QUIET = NO ./glibmm/docs/reference/Doxyfile:QUIET = NO ./gnutls-3.3.0/doc/doxygen/Doxyfile:QUIET = NO ./compiz-0.9.12.2/Doxyfile:QUIET = NO ./libcroco/Doxyfile:QUIET = NO
Created attachment 331663 [details] [review] docs: Make Doxygen silent
That's a real improvement. If you push your patch in glibmm, I can fix some other modules. Doxygen writes quite a few warnings, but warnings are written to docs/reference/doxygen.log, where they are only seldom noticed. I think it's best to keep it like that. Most of the warnings are irrelevant. Unfortunately, that's probably inevitable.
Review of attachment 331663 [details] [review]: Committed as: 3a7eddc02e492e6787e2e7bcefaa80c533fed009
@Kjell, I have just pushed it. In the mean time I also opened a pull request for FreeDRP: https://github.com/FreeRDP/FreeRDP/pull/3445#issuecomment-233314635 If you can also fix some other modules that would be great.
I have fixed atkmm, gtkmm, gtkmm-documentation, libsigc++, libxml++, mm-common and pangomm.