[cairo] COPYING files....

[Egbert Eich]

Keith Packard writes:
 > 
 > 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.

Right. The macros appearantly are applied to the *in files themselves,
therefore I cannot use the advantage of macro substituion to generate
the Makefiles.

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

More specifically the program generated by autoconf uses simple 
sed-style substitutions to generate a Makefile from a template.
This doesn't allow you to do stacked substituions and the use
of arguments as macro substituions do.

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

Right, I know all this.
Now my question is: can I extend these custom substitution rules and 
if so how?

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

This part is easy. This however just creates the driver object.
However the Imake macro above does more than just add a specific 
set of flags to a well known build rule. 
As I explained in my original email the macro also adds a command:
          cd $(BUILDMODULEDIR)/drivers && \
                $(LN) $(BUILDMODULETOP)/$${UP}$(CURRENT_DIR)/neomagic_drv.o .)
to this build rule. 
I guess my point is: 
I can extend any build rule macro to do non-standard things, I can do
this in one place and still the rule is applied to any Makefile.
To give another example:
The Xlib project has the line:
XLC_LOCALE: XLC_LOCALE.pre
        $(CPP) -traditional -DWCHAR32=1 -DXCOMM='#' - < $< > $@

in every nls/*/Makefile.am.
With Imake I'd have a makro definition:
#define BuildXLC_LOCALE @@\
XLC_LOCALE: XLC_LOCALE.pre @@\
        $(CPP) -traditional -DWCHAR32=1 -DXCOMM='#' - < $< > $@

in just one place. Every Imakefile would only contain
BuildXLC_LOCALE

If one decides that CPP doesn't suffice to preprocess the file but wants
to use another macro preprocessor, one only needs to modify the rule in
one single place.
(This is not the perfect example because the entire file is in fact
so generic that it could be replaced by a single include file. And
you could also use configure to substitute this rule as the macro
has no arguments)

 > 
 > > 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'.

Right, I understand that. It is not my point. I would like to know if
it is possible to use templates for custom build rules that go beyond
what you can do with suffix rules (I know that you could include a
file in every Makefile.am that predefines suffix rules but suffix rules
are not very flexible)

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

That I can't say. 
My main point is that automake (autotools) don't offer me the flexibility
in creating custom build rules. atuomake has build in custom build rules
for .elc files or processing texinfo documentation, however how do I add
my custom build rules.

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

I don't doubt that. However it may make other things more complicated
and less flexible. 
Right now while we are in a transition period I think it is only fair
to see which benefits the old build system had and how they could be
preserved. 


Cheers,
	Egbert.