[Fwd: Makefile support for packages using gtk-doc]
- From: James Henstridge <james daa com au>
- To: gtk-doc-list gnome org
- Subject: [Fwd: Makefile support for packages using gtk-doc]
- Date: Wed, 29 Jan 2003 14:26:37 +0800
Oops. I accidentally sent this to the wrong list.
James.
-------- Original Message --------
Subject: Makefile support for packages using gtk-doc
Date: Wed, 29 Jan 2003 14:19:04 +0800
From: James Henstridge <james daa com au>
To: gtk-devel-list gnome org
At the moment, setting up gtk-doc for a new package is fairly non
trivial. Setting up the Makefile is probably one of the more difficult
parts of this process.
Most people end up copying the makefile from another package and editing
a few variables at the top. This problem with this is that when people
find and fix bugs in their gtk-doc makefiles, the changes won't be
propagated to other packages that copied the makefile. It would be nice
if there was only a single gtk-doc support makefile that everyone used,
so that this wouldn't be a problem.
Newer versions of automake solve part of this problem with the "include"
command (the behaviour of this command changed between 1.4 and 1.5 --
before it would be passed through for make to handle. Now it is
processed by automake itself). A gtk-doc makefile might get reduced to
something like this:
--- cut here ---
# require automake >= 1.5 for include support
AUTOMAKE_OPTIONS = 1.5
# info about this module
DOC_MODULE = libglade
DOC_MAIN_XML_FILE = libglade-docs.xml
DOC_SOURCE_DIR = ../glade
GTKDOC_CFLAGS = ...
GTKDOC_LIBS = ...
...
include $(srcdir)/gtk-doc.make
--- cut here ---
All the complicated automake rules would be confined to a separate file:
gtk-doc.make. To copy the gtk-doc.make file, maybe a "gtkdocize" script
might be appropriate. It could then be copied in when autogen.sh is run
(it would need to be run before automake). There are a number of
situations that have occurred where this kind of setup would have helped:
* switch over to the new html style. many makefiles needed updating
to install the navigation images with the rest of the documentation.
* upgrading automake. With automake >= 1.5, "make distcheck" uses a
read only source directory. Having a single gtk-doc.make would
mean that there is only a single place to fix the problem. At the
moment, old gtk-doc makefiles are probably one of the things
slowing down the switch to up to date automakes.
If we adopt something like this, it might be worth revisiting whether it
is a good idea to provide a gtk-doc.m4 file. A few reasons for
providing one include:
* don't have to worry about broken gtk-doc version checks in
configure scripts. This was one of the pros mentioned last time.
* can provide consistent --enable-gtkdoc/--disable-gtkdoc configure
script arguments.
* the macro can make sure that all conditionals and makefile
variables needed by the gtk-doc.make fragment are defined.
What do people think of this idea? These additions would not break
existing packages, but make it easier for new packages to adopt gtk-doc
(and allow maintainers of existing packages to simplify the gtk-doc magic).
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]