[cairo] COPYING files....

[Egbert Eich]

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

To me that sounds really ugly. Configure is an excellent tool to 
obtain the system configuration. You have various degrees of freedom
to probe your system for whatever you desire. However what you suggest
here seems to exceed the scope of configure.
Imake has a strong side and a weak side:
The weak side is determining system specific configurations and selecting
the correct Makefile variables. 
The strong side is Imake's extensible capability to generate Makefile
rules from macros. 
The obscure thing about Imake is that it mixes these two together and
does them in one single pass. Over time noone was able to distinguish
any more what was a system configuration issue and what was a Make rule
generation issue.
autotools separate both issues nicely. However autotools have been designed
to solve certain problems. Automake was designed to make sure the GNU 
Makefile standard is met. It knows about those build rules that are 
frequently required by FSF projects.
When doing a big transition like converting a build system of a project
of considerable size to autotools it should be permitted to ask if the
old build system didn't have some features that are worthwhile preserving
and how this could be achieved.

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

I realize this and consider this to be a good thing.

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

That's an entirely different story. This works because configure can
probe certain things dynamically. Therefore we don't have to make 
assumptions about how things are on systems we don't even know precisely.

I'm talking about a completely different issue: creating of frequently
used complex Make rules from simple macros.

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

Right. And therefore I ask why we cannot spend some time to think about 
how things that were easier before can be preserved.

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

That's another issue which needs to be discussed.
I always felt that the links that were created by the old build system 
were a nifty thing which helped a lot during development. 
It allowes fast in place testing. It greatly speeds up the  modify/
rebuild/test cycle. For this purpose there is no need to copy files 
around: create a link instead when you rebuild a binary/library/module
and you are done. No need to do a 'make install'
I'm convinced that this will also be useful with a modular environment.
Therefore I would like to perserve this feature: at least as an option.

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

Right. I have looked and could not come up with anything. Maybe I should
look again.

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

Yes, in this perticular case it is, but only because the corresponding
Imake macro has no arguments.
 > 
 > 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.

A lot of what you called 'cruft' actually provided benefits for 
developers that seems to be missing from a lot of other build 
environments. At least is had simplified my work considerably.

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

Once the build system is in place the incentive to 'fix' it and
add missing features will be rather low. Therefore I'd suggest
to not postpone this and try to figure out how we can deal with
what is missing now. Once things are in place we can move on and
stop worrying about them.
There are still more things on my whish list ;-)

Cheers,
	Egbert.