[cairo] COPYING files....

[Keith Packard]

Around 12 o'clock on Feb 13, Egbert Eich wrote:

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

Yes, you really can -- it's just a matter of placing the macros in the 
configure.in script, assigning the results to variables and substituting 
those variable values in the Makefile.  That's pretty much the whole usage 
model.

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

Right.  All of the actual substitution happens in configure.in using shell 
syntax; the Makefile changes are all simply variable substitutions.  Note 
that you can also use this mechanism to modify other files, which is quite 
useful for system-dependent files for installation (like shell scripts, 
configuration headers, etc).

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

You don't.  You move the logic which you used to place in Imakefiles into 
the configure.in script.  This has the advantage of being programmed in 
/bin/sh instead of /lib/cpp, which means you can make it do a lot more 
sophisticated substitutions and detection.  Things like the current alloca 
nightmare (which resulted in Xalloca.h) are completely unnecessary.

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

Yeah, I can't immediately see how to make this work with automake, aside 
from sticking in a raw @foo@ in the Makefile.am.  As with any significant 
change, some things are easier and some are harder.  However, in this case 
the meta-answer is pretty easy -- we won't be doing this in a modular 
build, the driver will install itself right to the modules directory.

Perhaps we should look through the automake manual a bit more...

> To give another example:
> The Xlib project has the line:
> XLC_LOCALE: XLC_LOCALE.pre
>         $(CPP) -traditional -DWCHAR32=1 -DXCOMM='#' - < $< > $@

That's actually way easier -- again, you'd just have @BuildXLC_LOCALE@ in 
each Makefile.am and substitute in the above rule with configure.in.

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

Sure; anything you can do by constructing strings in configure.in and 
substituting them into the Makefile is easy enough.  However, the default 
rules in automake have covered the construction of pretty much everything 
I've wanted to build so far.  I don't see anything ahead which is 
significantly different from what we've already managed to produce.

I think that the proof will be in the pudding here; we've got the 
libraries and most of the X server building, let's carry on and see if we 
can't get the XFree86 drivers to build as well, I don't think it will be a 
huge amount of work.

A large amount of the complex cruft in the existing imake build system was 
caused by either the lack of access to /bin/sh in the Makefile 
construction process, or the need to perform the entire build inside the 
tree.  I'm hoping that most of this cruft will be unnecessary once we 
accept the default behaviour for most of the build tools instead of 
fighting it.

> 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 don't know how, but that isn't to say it can't be done (even easily, 
I've only done "normal" things with automake so far).

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

Preserved or transformed to fit the new build system architecture, to be 
sure.  I guess my main point is that automake has done (so far) almost 
exactly what I've wanted it to do in a wide variety of cases, things like 
the whole Xmu/Xmuu debacle just aren't an issue with automake, even xtrans 
is handled quite easily now.

I suggest solving each problem as we come to it; what has seemed hard in 
abstract has turned out to be relatively easy in practice.  Given that 
there is only finite code remaining to be converted, we can obviously make 
things work, even if not in the best way the first time.  We can go 
back and fix things as we learn more about using automake.

-keith