gnome-common macros stuff (was Re: pkg-config comments)

[Martin Baulig <martin home-of-linux org>]

James Henstridge <james daa com au> writes:

> Users don't care about the m4 file.  If people are building things from
> tarballs, then all the macros will be expanded beforehand, so it shouldn't
> matter.

Wrong. Users of binary packages don't need the macros, but people who're
compiling from tarballs do need them.

In the GNU world, source tarballs are the official way to get a release of
a given package (ie. the GNOME project only releases source tarballs, but no
binary packages - the binary packages are made by distribution vendors and
volunteers).

Assuming that noone will ever want to modify a configure.in file in a source
tarball is just lame.

A source tarball must work in a way that you can give the configure which is
contained in the tarball the --enable-maintainer-mode parameter and things
will works as if you were compiling from CVS (ie. you can modify things like
configure.in etc. and it'll rebuild stuff).

> > They only work if they're shiped in a package which users always must have
> > installed, such as gnome-common - otherwise you won't get a clear error message
> > if you don't have a recent enough pkg-config but some very confusing and weird
> > autoconf failures (so you won't be able to see from the error message that it's
> > pkg-config which you're missing).
> 
> If by users you mean people who download stuff from CVS and build it, then
> yes.  If you mean people who build stuff from tarballs, no.  I think we
> can require people who use CVS to install a tool like pkg-config.

It is just lame to distinguish between people who're compiling from tarballs
and people who're compiling from CVS - this implies that "we" (ie. the people
who're compiling from CVS) are something "better" than the others and that we
don't care about them.

The macros directory which is included by CVS magic has two disadvantages:

1.) It doesn't work for people who're developing their stuff outside GNOME CVS
    and for GNOME 2.x I don't want to have this difference any more.

    For GNOME 2.x I want people to be able to use and hack on the software no
    matter which transportation method they used to get the sources (and from
    a technical point of view, using CVS or a tarball to get the sources is
    just a transportation method) - there should be no difference between
    people inside and outside of GNOME CVS.

2.) It makes all source tarballs unnecessarily large (about 240k) which is a
    pain for modem users.

> > In GNOME 2.x we are already away from a macros directory, the macros are
> > installed by gnome-common, so that all applications - no matter whether they're
> > in GNOME CVS or outside of it - can use them.
> 
> I thought the agreed on solution was to distribute these macros with the
> libraries/programs they are written for (where they belong).  Having them
> in a special macros package is basically the same as what we have now.

According to my (now very good, however) memory, there was some discussion
about this, I told people how broken this is and then we "agreed" to use it
nevertheless because we don't care about tarball users and people developing
outside of GNOME CVS because "if they're using CVS they'll have this stuff
anyways" or something like this.

Our macros directory has a lot of useful features and it has proven to work
for a very long time.

And gnome-common is the same as what we have now - minus all its disadvantages
plus a few additional features.

If you're trying to autogen.sh the CVS version of some package, but you don't
have gnome-common installed, you get a very clean error message:

        $ ./autogen.sh --prefix=/gnome/unstable/INSTALL
        ./autogen.sh: gnome-autogen.sh: No such file or directory

But if you're missing some .m4 file, you don't get a clear error message at
all - you can be lucky if aclocal/autoconf aborts with a message about a
missing macro - if you don't just get a parse error somewhere in configure.

To summarize all the problems that installing .m4 files together with the
package have:

a) You cannot use the .m4 file which is distributed with a package to check
   whether you have this package - as soon as you use one of the macros from
   this .m4 file, you must already have the package installed, so checking for
   it is useless.

   With the current setup, we use the macros to check whether you have some
   package and to print out a reasonable error message if not - this is very
   important for new developers: if they forget to install some package (for
   instance because they don't know that they need it), there'll be a clear
   error message which tells them that this package is missing and where they
   can get it.

   We can not abandon this and just assume that you'll be compiling from
   GNOME CVS anyways and that you'll have all possible packages anyways.

b) Logical consequence of a) is that it'll be impossible to have any optional
   dependencies.

   This means, that for instance a package like libglade will _require_ Bonobo
   just to be able to check whether you have Bonobo (since, according to a),
   checking whether you have a package, already means that you must have it
   installed).

And for this "oh pkg-config does wonders" league - pkg-config is wonderful and
nice tool, but it cannot do everything - and especially it is impossible to go
without the macros in gnome-common if we switch everything to pkg-config:

c) [this is not an argument, so continue reading with d.)]

   pkg-config is a tool which is under development and without the macros in
   gnome-common there's no way to check for a particular version of pkg-config.

d) pkg-config can only be used to check for things which "we" (ie. the GNOME
   project) maintain, but not for system libraries and operating system details.

   There won't be much such things, but there are a few.

e) When you check for things which are developed outside of GNOME CVS and have
   a .pc file - just using pkg-config to check for them is ultra-lame since
   it'll abort with a "checking for foo .... not found" and how the hell do the
   person who's getting this error message know what is `foo' and where he can
   get `foo' ?

   The correct thing to do this is to use AC_MSG_ERROR to print out a good
   error message which tells the person who's compiling the package where he
   can get this stuff.

   For such stuff it's just very convenient to have a m4 macro somewhere which
   you can use.

So I don't see a reason why we need to break everything and install the m4
files with the packages while the gnome-common module is working so perfect.

I hope to be able to make a new gnome-common release in one or two weeks which
will include:

i) For the GNOME 1.x platform, I cannot change anything in the macros/ dir
   since this is distributed all over CVS. But it isn't at all necessary to
   change anything in it since the most important point is that it'll be able
   to use the m4 macros in projects outside of GNOME CVS in the same way as
   we do in GNOME CVS.

ii) At the same time, I'll finish the documentation for the GNOME 1.x platform,
    provide some usage instructions and switch GTop to use gnome-common so that
    people can look at it as an example on how to use it.

iii) For the GNOME 2.x platform, I'll finish all the things which I started, so
     that it'll become actually useful.

     This will contain:

     - An easy way to have a configure command line argument to specify the
       GNOME platform (1.x or 2.x) which will provide some automake conditional
       and #defines etc.

       This'll allow you to smoothly migrate your package to use things from
       the GNOME 2.x platform, for instance glib HEAD etc.

     - macros to easily use pkg-config.

iv) Clean up the macros2/ directory, remove stuff which should be local to
    packages etc. so that only generally useful stuff will be left.

v)  Fully document all macros in macros2/ and the most useful macros in macros/.

vi) Write up a nice document which explains how to use this stuff, etc.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)