The only change that you may wish to consider here is to make your package's autogen.sh script call the gnome-autogen.sh script with the USE_GNOME2_MACROS environment variable set. For example, see the sample autogen.sh script below. In general, it's fairly safe to just copy the autogen.sh from somewhere like the gnome-hello modules and just modify the package name.

#!/bin/sh
# Run this to generate all the initial makefiles, etc.

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

PKG_NAME="Gnome Hello Demonstration Application"

(test -f $srcdir/configure.in \
  && test -f $srcdir/ChangeLog \
  && test -d $srcdir/src) || {
    echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
    echo " top-level $PKG_NAME directory"
    exit 1
}

which gnome-autogen.sh || {
    echo "You need to install gnome-common from the GNOME CVS"
    exit 1
}
USE_GNOME2_MACROS=1 . gnome-autogen.sh
         

As mentioned in the short description of pkg-config, this is the new way to do things that were previously done with calls to application specific scripts like gnome-config.

You can list all of the libraries that are under pkg-config management by running the command pkg-config --list-all. If you do this, you'll see that all of the libraries that are part of the GNOME 2 platform are known to pkg-config.

In almost all cases, it is sufficient to find the platform libraries that are the highest in the tree of dependencies. That is, the library whose dependencies includes all of the other libraries you will need. Usually, libgnomeui-2.0 is sufficient, since it's dependencies include gtk+, gconf and libbonoboui amongst others. Have a look at the Module dependencies appendix for a graphic showing all of the dependencies between various modules.

If you think you need something more specific or more complex that this, have a look at the pkg-config manual page for more information.

For using packages that are managed by pkg-config, all of the changes are in configure.in which is covered in the section about required changes to configure.in. If you are looking to make your own package usable via pkg-config, then you need to create an appropriate foo.pc file (if your package is indeed called foo).

Typically, you would not create foo.pc directly, since it contains information about the installed location of the components of foo. Rather, you would create foo.pc.in with appropriate variables that can then be filled in from configure.in. By way of example, here is a slight variation on the gobject.pc.in file (the Conflicts line is not normal and there are some extra comments). This file would then be turned into gobject.pc via an appropriate line in the AC_OUTPUT section of configure.in.

# This is a comment
prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@

Name: GObject                            # human-readable name
Description: Object/type system for GLib # human-readable description
Version: @VERSION@
Requires: glib-2.0 = 1.3.1
Conflicts: foobar <= 4.5
Libs: -L${libdir} -lgobject-1.3
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib/include
         

Most of this should not be too surprising for people used to compiling programs: specify the required libraries, the linking and C flags for this package and anything it conflicts with. For more example, look in the standard location where pkg-config stored the *.pc files (usually $(prefix)/lib/pkgconfig/.

The configure.in file is probably the one that requires the most changes from amongst those that are part of the application build infrastructure. There are a variety of reasons for this.

For GNOME 2, the need for every CVS module to have a macros/ subdirectory containing a whole group of common .m4 macros has been removed. Instead, the common macros are part of the gnome-common module and will normally be available (when installed) under $(prefix)/share/aclocal/gnome2-macros.

Similarly, there is generally little need to use the gettext from the intl/ directory that is in most modules, since gettext is generally already installed on the developer's machine.

Finally, some changes are required due to the upgrading of various tools. For example, some are recommended as part of the move to autoconf 2.52. These allow better diagnostic messages, for the most part. The inclusion of pkg-config will also require the addition of a few calls.

Of course, as with all of the suggestions throughout this document, if you need something more complex than the above, you already understand why you need something different and know enough to change it. This document simply provides a checklist for the majority of applications in this document; it won't necessarily work for some really tricky corner cases.

So now that the justifications are out of the way, here are the steps that will work in most cases:

Usually, you will not need to make substantive changes to your Makefile.am, since it already just contains the minimal amount of information needed for you application to build. The main thing you should do is remove any references to the intl and macros directories in targets like DIST_SUBDIRS and SUBDIRS.

In the section on Scrollkeeper support we will discuss some Makefile.am changes that are required for adding Scrollkeeper support to your document. Similarly, in the section on Signal Marshallers we discuss some Makefile.am changes that are required if you need to generate signal marshallers in gtk.