Re: gnome-doc-utils, automake 1.9, and -Wno-portability

[Daniel Macks <dmacks netspace org>]

On Mon, Feb 16, 2009 at 11:01:04AM -0600, Shaun McCance wrote:
> On Mon, 2009-02-16 at 11:27 +0200, Stefan Kost wrote:
> > Shaun McCance schrieb:
> > > Ever since automake 1.9, automake has been spewing garbage like
> > > this when you try to build any module that uses gnome-doc-utils:
> > > 
> > > http://bugzilla.gnome.org/show_bug.cgi?id=507336
> > 
> > Does anyone know what a fix would be? What are the rules for "POSIX variable
> > name"? Most hits I get when searching for that error tell that its becausem fo
> > e.g. $(shell ...), but this isn't a variable name. Is the warning maybe crap and
> > it should be filed as a bug to automake?
> 
> Basically, these "variables" are in fact function calls.  These
> make functions are GNU extensions.  Options:
> 
> 1) Completely rewrite gnome-doc-utils.make to not use these
> functions.  Comment #3 shows a glimpse of what that would
> involve.  But it only covers some of the easier cases.  I
> don't have a lot of confidence I could get it completely
> working.  And, of course, that is a *huge* change that
> would need lots of testing.

Indeed, some $(FUNCTION are quite harder to clean up strictly using
shell in the makefile.

> 2) Rodney indicated on IRC that this problem doesn't happen
> for intltool, because it includes its bits using AC_SUBST.
> He seems to think that if we used AC_SUBST_FILE instead of
> doing an include, the warnings would disappear.  This looks
> like a loophole to me, and I wouldn't be surprised if the
> automake developers closed it off in a future version.
> Note that, with this option, gnome-doc-utils will still
> not work with non-GNU makes.  You just won't see warnings
> telling you so.

Along the same lines (though cleaner, or maybe the same, given that I
don't understand intltool) would be to do in the configure script
whatever logic the $(FUNCTION are doing, and then AC_SUBST the
results. However, if...

> 3) Decide that we don't support non-GNU make, which we
> already don't.

that's true, then all we need to do is shut up the warning *somehow*.
Don't need to fix problems that only affect a program that isn't
allowable anyway. If that's true, would be good to get an autoconf bit
to test for it though:
  checking for GNU make... no
  Error: gnome-doc-utils requires 'make' that supports GNU Makefile
         extensions.
to avoid later hard-to-diagnose problems during 'make' if there aren't
warnings about makefile portability issued.  Is there a way to hide
only the makefile portability warnings (rather than *all* portability
warnings)?

dan

-- 
Daniel Macks
dmacks netspace org
http://www.netspace.org/~dmacks