Re: patch to build glib with automake 1.6/1.7

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-02-27 at 21:01, James Henstridge wrote:
> I have attached a patch to bug 74706 that gets glib HEAD to build with 
> automake 1.7:
>      http://bugzilla.gnome.org/showattachment.cgi?attach_id=14674

First question: Are you volunteering to do the same thing for 
Pango/ATK/GTK+ and to maintain this for (some period of) the future? 
:-) I'm going to have to review this a lot more closely, if it's a
one-shot deal.

> With this patch, I was able to successfully complete a "make distcheck", 
> which uses a readonly source directory with newer automakes.  Some of 
> the interesting parts of the patch include:
>    - autogen.sh changed to use automake 1.7 or 1.6.  It also calls
>      libtoolize and gtkdocize.

I think we should require exactly 1.7. Trying to handle multiple
automake versions is just going to cause problems for no good
reason, since the end product is the distributed tarball, which
will use exactly one automake version.

Yes, it makes it a little harder to build from CVS, since 1.7 isn't
widely available yet, but I don't think it will be that bad..
(I can put automake-1.7 RPMS up somewhere.)

>    - some cleanups in the configure.in script.  We already require newer
>      autoconf's, so may as well make use of it.  The
>      GLIB_AC_DIVERT_BEFORE_HELP() stuff isn't really needed anymore.

Doesn't really work any more, you mean... see:

 http://bugzilla.gnome.org/show_bug.cgi?id=106348

for my take on the problem. It's probably worth making the pango 
and GLib/GTK+ stuff exactly the same.

>    - fix documentation makefiles to use the gtk-doc.make file installed
>      by gtkdocize.
>    - fix up the po/Makefile.in.in file's update-po rule to work okay
>      during distcheck (uses some of the rules from newer gettext's).
>    - fix up "make uninstall" and "make distclean" so that they remove the
>      corresponding files.  This is needed to make distcheck pass.
>    - replace some uses of @foo@ with $(foo) in the makefiles.  This
>      allows Automake can do a better job warning about undefined
>      variables where it matters.
> 
> What do you think of these changes?

They mostly look OK. Detailed comments below.

> I know it is out of the question to apply all of this to the glib-2-2 
> branch, but is there any chance of applying the po/Makefile.in.in fixes 
> to the branch?  Without those changes, Gnome 2.4 packages using 
> glib-gettextize are going to have trouble distchecking with recent 
> automakes.

Hmmm, the po/Makefile.in.in changes look less extensive than I feared.
Let's go ahead and make them in the glib-2-2 branch. 

Regards,
                                         Owen

* Your configure.in entry doesn't look complete. That's OK, just
  make sure it's complete before committing.

* I don't think a lot of the DISTCLEAN additions are right:

 -DISTCLEANFILES = glibconfig-sysdefs.h glibconfig.h stamp-gc-h 
 +# build documentation when doing distcheck 
 +DISTCHECK_CONFIGURE_FLAGS = --enable-gtk-doc
 +
 +DISTCLEANFILES = glibconfig-sysdefs.h glibconfig.h stamp-gc-h config.h.win32 \
 +  glibconfig.h.win32 README INSTALL

 By the GNU standards (and logic) distclean shouldn't remove files
 that are included with the distribution, like the files you've added
 here. I guess the problem you are try to solve is that
 AC_OUTPUT_FILES() generates the files even if they already exist 
 in the same form in the sourcedir. 
 
 I guess the two options here are:

  - Use AC_SUBST() and makefile rules instead of generating these
    files from configure.in

  - Modify the distcleancheck rule to simply ignore these files. 
    (See discussion in the automake manual)

 I don't have much of an opinion between the two; the second seems
 bit easier.

* gtk-doc didn't used to be a requirement when building from CVS,
  but now is due to the use of gtkdocize. autogen.sh should check
  in a clear fashion for it; right now, I think it will just
  fail, scroll by, then fail during Make.

* Probably need to add docs to hacking about 
  autogen.sh --disable-gtk-doc for people without working XML
  setups; it used to at least be that such people might not
  have installed gtk-doc. Or does GTK_DOC_CHECK() check for working
  xlstproc (docbook dtd, dsl stylesheets) as well as gtk-doc
  installed?

* I think we probably should go ahead and use quadrigraphs
  (urgh!) to keep [] in the configure.in output since the standard
  option use [] for similar cases.

  That is, instead of"

-AC_ARG_ENABLE(debug, [  --enable-debug=[no/minimum/yes] turn on
debugging [default=$debug_default]],,enable_debug=$debug_default)
+AC_ARG_ENABLE(debug,
+              [  --enable-debug=[no/minimum/yes] turn on debugging
(default=glib_debug_default)],,
+              enable_debug=glib_debug_default)

  Go with

 AC_ARG_ENABLE(debug, [  --enable-debug=@<:@no/minimum/yes@:>@ turn
 on debugging @<:default=glib_debug_default@:>@]], ..

* Generated sources. What fun :-)

   $(libgobject_2_0_la_OBJECTS): $(gobject_built_sources) 
${gobject_built_public_sources} # this is our oldest file, used for
implicit auto-generation deps

 I was hoping that we could ditch this in favor of BUILT_SOURCES
 with newer automake. 

-$(srcdir)/stamp-gmarshal.h: @REBUILD@ gmarshal.list gmarshal.h
glib-genmarshal$(EXEEXT)
+gmarshal.h: @REBUILD@ gmarshal.list glib-genmarshal$(EXEEXT)
 
 Doesn't this remove the stamp-file handling, and thus cause
 unnecessary rebuilds? (Note that maybe the stamp file isn't
 needed here since if gmarshal.list changes, gmarshal.h probably
 changes, but then it needs to be more comprehensively removed.)

 The stuff in gdk/Makefile.am is (to my knowledge) the best
 practices way of handling stamp files. 

 $(srcdir)/gdkenumtypes.h: stamp-gdkenumtypes.h
         @true 
 stamp-gdkenumtypes.h: @REBUILD@ $(gdk_public_h_sources) Makefile
         ( cd $(srcdir) && glib-mkenums [... ] )

 I think this method should still work when generating files
 in the build dir.

 Considerations:

  - We have to generate source files in the build dir for
    distcheck to work with new automake, since it chmod's
    the source dir.

  - Any source files that are generated via glib-mkenums
    must be distributed with the tarball. Files generated
    with glib-genmarshal don't need to be distributed.

  - We need to make sure that if there are versions of a header
    file both in the source dir and the build dir, the build
    dir gets known.

  - glib-mkenums source files really must be stampified,
    but glib-genmarshal source files probably don't
    need stampification.

* Fine detail ... might by good to remove $tmpdir/$$lang.new.po
  if the mv fails before exiting. (Checking for failure here
  seems a little bit superfluous, but if you are going to check,
  might as well go all the way.)

+	      if mv -f $$tmpdir/$$lang.new.po $$lang.po; then \
+	        :; \
+	      else \
+	        echo "msgmerge for $$lang.po failed: cannot move
$$tmpdir/$$lang.new.po to $$lang.po" 1>&2; \
+	        exit 1; \
+	      fi; \