[cairo] COPYING files....

[Keith Packard]

Around 15 o'clock on Feb 11, Egbert Eich wrote:

(sorry for the delay in responding)

> So far I have seen autoconf and automake as two separate entities
> where autoconf picks up where automake leaves off. Maybe I'm wrong.
> You have the chance to proof to me that I am ;-)

Automake is a combination of a new utility which constructs the 
Makefile.in from Makefile.am and additional autoconf macros that make 
building the configure.in script easier.

The basic difference between imake and autoconf may be as simple as 
autoconf constructs a program to build a Makefile from a template while 
imake just builds a Makefile from a template directly.  There's a lot to 
be said for the latter method as it removes another layer of indirection 
from the process.

> It looks to me that autoconf m4 macros don't act on Makefile.[ac,im] 
> but are used to create the configure script - a script that both checks 
> the details of system configuraton and replaces @????@ strings in *.in 
> files.

The configure script acts on Makefile.in; however, Makefile.in is built
from Makefile.am by automake using essentially custom substitution rules.
Those rules permit a relatively clear specification of the build process to
generate a sophisticated Makefile.in template that the configure script can
use to construct a Makefile capable of building the system on a huge range
of platforms.

> To give a specific but very simple example:
> If I want to build a driver module for XFree86 I add the following
> macro to an Imakefile:
> 
> ObjectModuleTarget(mydriver,$(OBJS))

Ah, I see what you want -- you want a mechanism to construct macros for 
building custom compiler output rules.  It's not autoconf's m4 macros that 
you use in this case, but the naming conventions that automake uses to 
construct the Makefile.in template from Makefile.am

Here's how you'd do that in automake:

	libmydriver_a_CFLAGS = @OBJECT_MODULE_CFLAGS@
	libmydriver_a_SOURCES = foo.c bar.c

To get special C flags or loader options into this, you'd use configure.in 
rules that detected the right values and substituted them into the above 
rules.  You could even substitute in custom tools to construct the library 
from the object files.

> Imake will expand this to a full build rule which doesn't only
> build the object (the correct flags are all known to the macro
> so I don't have to worry about them when I do the Imakefile),
> it will also symlink the driver into the exports/drivers directory.

Automake already does this.  You can create custom cflags/ldflags for each 
module as well from configure.in macros, and you can create custom install 
rules if you want.  For drivers, I don't anticipate doing anything other 
than a regular install; modularizing the drivers means never building them 
'in-tree'.

> > If we find ourselves wishing for shared custom autoconf macros, 
> > we can (as gnome does) create a small module that installs those custom 
>  > autoconf macros in the build system.
> 
> Do we need to install these?

I envision installing them; gnome has a package full of this kind of stuff 
which gets installed before the main packages are built.

I don't know if we'll need any custom macros; we haven't needed any to 
date.

> I used to believe that, too. When I tried to build Xlib configure failed
> horribly (with a syntax error, not a sane error message) when I did not
> have pkg-config installed.

Yes, pkg-config doesn't really follow the general autoconf philosophy of 
not requiring any special tools.  I'm of two minds on this issue; 
pkg-config eliminates a huge amount of nasty configuration code to 
construct the right options for each library, but it requires pkg-config 
to exist on the build system.

I suggest that the big questions about autotools that remain surround X 
server compilation, especially driver modules, which is one place where X 
is significantly different from the run-of-the-mill Linux package.  The 
easiest way to find out how hard this is will be to go and try it.  I 
don't see anything that will be 'impossible', and I'm actually hoping that 
some things are easier.

-keith