GNOME.org
 

Re: patch to build glib with automake 1.6/1.7

Owen Taylor wrote:


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.
I can take a look at those after getting the glib patch in. I just started with glib because it is at the bottom of the stack, and also fits into the "tool" category due to glib-gettextize. I can go through any bug reports caused by the build changes (not for ever though).
I also intend to write up some notes on the porting process, which can be used by other maintainers wanting to switch.
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.)
Okay. I can change the autogen.sh script to require 1.7. There are probably some other cleanups possible if we require automake-1.7, since a number of bugs related to conditionals were fixed (the main one is that += works inside a conditional block in a makefile). 


  - 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. 


Okay.  I can look at them when I get to those packages.

[snip]


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.
Okay. I will prepare another patch for glib 2.2 afterwards (with the suggestions you mention below).
I will probably need to push through an intltool patch at the same time, since this will most likely break the patch it applies to the glib-gettext Makefile.in.in. 



Regards,
                                        Owen

* Your configure.in entry doesn't look complete. That's OK, just
 make sure it's complete before committing.
I have some more configure.in cleanups in my local tree that I'll include in the next revision of the patch. 


* 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
"make distcheck" complains if you leave any files in the builddir, which is why I added them like that. I suppose it would be better to change it to look something like this: 
 distclean-hook:
         if test $(srcdir) != .; then \
             rm -f ...; \
         fi
So that if will remove the version in builddir if srcdir != builddir. I think "make dist" will pick up the version in builddir if it exists, but I will have to check this. 


* 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.
Yep, that should be fixed. It is probably worth getting the autogen.sh script to exit on error from any of the tools it executes. This is what the gnome-common autogen.sh script has been doing for a while (from before I hacked on it :)
* 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?
Currently GTK_DOC_CHECK() doesn't check for xsltproc and a working xml catalog, but gtk-doc's configure script does perform these checks. It shouldn't be too difficult to move the checks into gtk-doc.m4.
I am not sure what to do about people using systems without an XML catalog. One option would be to point them at http://scrollkeeper.sf.net/docbook.shtml, which provides an easily installable package containing the v4.1.2 DocBook DTD and v1.48 of the stylesheets.
It might also be worth providing a simple script for Debian users to build up a catalog from the packages installed on their system while they are finishing off their "xml-base" package. 


* 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. 
You are right.  I've removed that bit in my local copy now.


-$(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.)
I have readded the stamp file handling in my local copy, and things seem to be building fine now. 


* 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; \
Good catch. Fixed in my local copy. It looks like I copied that mistake directly from gettext's Makefile.in.in ... 


Thanks for the feedback.  I will post a newer patch later on today.

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]