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 _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
