(In reply to comment #0)
> On this page he explicitly talks about how you can make use of silent and still
> have the backwards-compability.
> 
> http://www.flameeyes.eu/autotools-mythbuster/automake/silent.html

Which is exactly what we've done:

In xorg-macros 1.3:
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])

In libX11/configure.ac:
# Support AM_SILENT_RULES if automake-1.11 or later is used
m4_ifdef([AM_SILENT_RULES],[HAVE_AM_SILENT_RULES=yes])
AM_CONDITIONAL(HAVE_AM_SILENT_RULES, test x$HAVE_AM_SILENT_RULES != x)

We know gentoo has broken automake, with 1.10 & 1.11 being mixed somehow,
which the gentoo devs are working to put a workaround for in their X builds,
perhaps your unspecified platform has as well?   Without more detail of what
you're seeing that appears broken or how to reproduce, there's nothing we can do.

(In reply to comment #1)

> We know gentoo has broken automake, with 1.10 & 1.11 being mixed somehow,
> which the gentoo devs are working to put a workaround for in their X builds,
> perhaps your unspecified platform has as well?

I am using gentoo, but this has nothing to do with automake being mixed, just some wrong assumption on how autotools behaves.
The problem is that with your ruleset autoconf with older automake still exports HAVE_AM_SILENT_RULES as true and cpprules.in picks it up no matter what version of automake you have. This fails big time.

Created attachment 29881 [details] [review]
Make-older-autotools-not-barf-with-AM_SILENT_RULES

Here is something that really works, both with automake-1.10 and 1.11.

I think I found out what you based your claim on (a user reporting on the maillist taht he could not build with portage), and the "brokenness" you saw is that portage in gentoo rather uses automake-1.10 then 1.11 if you do not tell it to do so.

So the "brokeness" there was that portage choosed automake-1.10 when bootstrapping libX11 from git, and your buildsystem does not work with it currently.

This is workearound in the portage ebuild currently, but fact stands: the buildsystem fails with older automake.

So please apply a fix that works even for people using old automake, like the patch provided.

Also in the future please refrain from tell people something is broken, unless you are sure. Better tell them you NEEDINFO. Otherwise you just upset people.

And please excuse me if I sound harsh. I am just so tired of hearing people telling me that gentoo is broken when it is not.

(In reply to comment #4)
> I think I found out what you based your claim on (a user reporting on the
> maillist taht he could not build with portage), and the "brokenness" you saw is
> that portage in gentoo rather uses automake-1.10 then 1.11 if you do not tell
> it to do so.

And that it was coming up with AM_SILENT_RULES as defined when it was using
automake 1.10 and should not have been.

> This is workearound in the portage ebuild currently, but fact stands: the
> buildsystem fails with older automake.

I swear it worked on the automake 1.10 system I originally tested on, but
on another system I notice a very weird case.   It correctly detects that 
the AM_SILENT_RULES are not present and sets the flags appropriately:
 
% grep SILENT config.log
HAVE_AM_SILENT_RULES_FALSE=''
HAVE_AM_SILENT_RULES_TRUE='#'

The lines in nls/Makefile.in should thus be commented out when building
Makefile:

# Support for automake 1.11 AM_SILENT_RULES
@HAVE_AM_SILENT_RULES_TRUE@cpp_verbose = $(cpp_verbose_$(V))
@HAVE_AM_SILENT_RULES_TRUE@cpp_verbose_ = $(cpp_verbose_$(AM_DEFAULT_VERBOSITY))
@HAVE_AM_SILENT_RULES_TRUE@cpp_verbose_0 = @echo "  CPP   " $@;

But they are not.   config.status shows both are set empty:
config.status:S["HAVE_AM_SILENT_RULES_FALSE"]=""
config.status:S["HAVE_AM_SILENT_RULES_TRUE"]=""

> Also in the future please refrain from tell people something is broken, unless
> you are sure. Better tell them you NEEDINFO. Otherwise you just upset people.

Our bugzilla has no NEEDINFO state, but I was trying to indicate we needed info.
So far, only gentoo users had reported issues, and their developers had 
indicated they were looking at a problem, so it didn't seem unreasonable.

> And please excuse me if I sound harsh. I am just so tired of hearing people
> telling me that gentoo is broken when it is not.

Believe me, we all understand, being flooded with bug reports insisting our
software is broken - sometimes it is, sometimes it's not.

(While I could close this as NOTOURBUG, since it appears to be automake-1.10
 failing to handle an #if clause properly, that wouldn't be useful, since the
 fix would be to upgrade to 1.11 anyway.)

Doh!  Hit commit just a minute too soon - found the bug - it's simpler
and stupider and easier to fix than that.   The AM_CONDITIONAL simply
needs to be *before* the AC_OUTPUT that creates the Makefiles & config.status:

config.status:S["HAVE_AM_SILENT_RULES_FALSE"]=""
config.status:S["HAVE_AM_SILENT_RULES_TRUE"]="#"

nls/Makefile:#cpp_verbose = $(cpp_verbose_$(V))
nls/Makefile:#cpp_verbose_ = $(cpp_verbose_$(AM_DEFAULT_VERBOSITY))
nls/Makefile:#cpp_verbose_0 = @echo "  CPP   " $@;

Will commit fix as soon as test build finishes.

I still do not see the need of those cpp_verbose when automake has it built in, as used in my patch.

I've committed the simple fix for now:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=69839f8903a24eab08f17a781b3797fb64dce9cf

I don't remember why, when given the two choices in the automake 1.11
manual, I chose the custom rules over the AM_V_GEN - I'll try out your
patch and see how that works.

(In reply to comment #8)
> I don't remember why, when given the two choices in the automake 1.11
> manual, I chose the custom rules over the AM_V_GEN - I'll try out your
> patch and see how that works.

Ah yes, it's the difference between printing "CPP" vs. printing "GEN".

Will ask on xorg-devel if people want to see the greater detail of "CPP"
or not.

Looks like this was fixed?