[Axiom-developer] out of source builds

[daly]

That said, I believe the new build system is a useful change to
the system. There are two different issues which seem to be
orthogonal. 

One, addressed by the autoconf system, is the question of what
facilities are available on the current system. It appears that this
is covered quite well by the configure tool. It seems that this tool
created the proper global variables to find and use avaiable tools.

The second issue is what to do with these tools. The current system
mixes the tool configure settings with the `basename $AXIOM` settings
in Makefile.pamphlet. This is clearly wrong and should be fixed.  It
would be possible to use the autoconf configure to set global
variables in the Makefiles in the current system, which would represent
an incremental step along the path to the new build system.

So perhaps the first thing to try is just merge autoconf. This would
be much less work than a complete, monolithic merge and might add
significant benefit immediately. Even if we fully convert to the
whole new Makefile tree this is still a useful intermediate step.

It seems to me that the build system we want is actually a mixture of
the two existing systems. The current architecture is not all bad and
takes into account various axiom-specific needs. But it does not address
modern tools like configure.  I suggest that we discuss design goals
based on real requirements.

One design goal is minimizing build times. This is obviously 
important to developers. It also allows us to push out a patch
that would only take minutes to apply. (Hence, "int")

Another is "incremental rebuilds" (otherwise why use make?). This
is related to the first point. It should be possible to blow away
small portions of the system (e.g. an input file, hyperdoc pages,
the graphics, etc) and do a small rebuild. (Hence "PART="). The
PART= tool is also useful for adding/skipping things like Stephen's
new AXISP parser.

A third would be "axiom (i.e. zips) versions" versus "user (i.e.
/usr/local/bin) versions" of tools like lisp. Even with autoconf
there are times that we want to advise using a "known good" version
of tools. (Hence "zips")

A fourth issue, probably most valuable to me if not others, is the
"debugability" issue. The current build system puts out a unique
number in front of every build line so we can find the exact failing
stanza. This allows us to find and fix bugs rapidly. (Hence "echo #")

A fifth issue is out of source builds. That issue has been raised but
I'm not sure why it is important. I know of no instance where anyone
builds from CD sources for any open source project. CD readers are
much too slow compared to hard disks so that would seriously impact
the build times. I obviously agree that it should work since the
current build system is designed to do it. (Hence "SRC=")

What other design goals are there? 
How does the current system succeed or fail at achieving those goals? 
How does autoconf succeed or fail at achieving these goals?


Tim