[cairo] COPYING files....
Egbert Eich
eich@xfree86.org
Wed, 11 Feb 2004 15:02:46 +0100
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.