Re: [cairo] COPYING files....

Keith Packard writes:
 > 
 > Around 18 o'clock on Feb 10, Egbert Eich wrote:
 > 
 > > Adding/Modifying  automake rules would probably involve hacking the 
 > > 10k loc automake perl script. The only other way of adding new rules
 > > to automake I can think of would be the creation if include files
 > > which define suffix rules. However these are much less flexible than
 > > the macros.
 > 
 > Autoconf uses m4 as a macro language, which is unarguably more appropriate
 > for this task than CPP, but functionally similar.  Adding autoconf macros 

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 ;-)
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.
It doesn't seem to apply m4 rules to these.
I don't see how it would create full build rules using dependencies
specified in the Makefile.ac.

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

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.
If I want to do something else with the object (for instance dump
all exported symbols to an file 'mydriver.map' or whatever else) 
I simply change one macro at one place. When I regenerate the 
Makefile ('make Makefile' is all the magic required) the new rule 
is in place.

Now how would something similar work with automake/configure/m4 
and friends?

 > is precisely the same as adding imake macros, only the language used to 
 > implement them is different.  If you look at how pkg-config integrates 
 > with autoconf, it does so by distributing a file full of custom autoconf 
 > macros.  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?

 > 
 > The nicest part about all of this is that once the tarballs are built, the 
 > target system need have *none* of the autoconf/automake tool chain 
 > installed.

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.

 > 
 > > autoconf and libtool probably have grown out of the GNU project. 
 > > automake may not. At least that's what I get from reading the texinfo 
 > > docs that come with it.
 > 
 > I think this slightly overstates the case; automake does make more 
 > assumptions about the structure of your project than autoconf, that is one 
 > of the ways it reduces the amount of work needed to create a good 
 > build architecture for your project.  However, after automaking several 
 > dozen projects, I haven't found it particularily GNU-centric, aside from 
 > it's annoying habit of sticking the GPL license into your directory (which 

GNU centirc are the special rules for generating *.elc files from emacs lisp
files and create various forms of documentation from texinfo files.

 > can be disabled with command line options).  I look at that behaviour as a 
 > little bit of harmless FSF evangelism, more or less like being handed a 
 > flower by a hari krishna at the airport.
 > 

Has this ever happened to you? I've always heared of this but it has
never actually happened to me ;-)

Cheers,
	Egbert.