> Axiom's a pretty complex system, and it seems to have picked up a bunch > of other projects like clef, noweb, and gcl, and like all good lisp > systems, even recursive project dependencies like gcl has it's own bfd, > and gmp. > > There is still a set of external dependencies that have to be satisfied, > like pdflatex, gcc, and others. > > The recent clef/readline thread points out it may be advantageous to > review the list of internal and external dependencies, and prune some cod= > e. > > What are people thinking about the builds of axiom? Debian tries to > patch axiom to use system supplied tools and libraries where possible, > the Mac OS X port tries to use local copies of everything. > build-improvements stated goals are to automagically pick up any > installed copies and build the rest internally. > > I ask because I had to mangle ./configure to fix a test for > malloc/malloc.h on Intel Mac. Neither of the autoconf programs installed > on my Mac like the configure.in in gcl-2.6.8pre: > > $ /sw/bin/autoconf --version > autoconf (GNU Autoconf) 2.60 > > $ /usr/bin/autoconf --version > autoconf (GNU Autoconf) 2.59 > > configure says it's been generated with autoconf 2.13. > > I guess there's really no way to ship axiom with it's own autoconf if we > have any expectation of using configure to build axiom, but how far down > do we plan to go? I saw Gaby is seriously considering integrating gcl > and gcc.
Well this is a long running controvery with opinions ranging from rewriting Axiom completely in Aldor to the current bundle (which except for noweb, gcl, and latex) are all part of the commercial version, to the more extreme case of fully bundling GCL and noweb. Since opinion varies widely on this it will continue to be debated, which is the point, really. I'm working from a philosophy that borders on the pragmatic with a focus on the long term (the 30 year horizon). We need to try to invent the environment and the organization of computational mathematics that will be considered "state of the art" in 30 years For example, we might consider a system that allows direct manipulation of n-dimensional varieties. This would correspond to the underlying mathematics similar in spirit to current solid models based on mathematical relationships such as spline curves or finite meshes. In the middle term we need to critique the current methods (e.g. textual literate programming) and seek out new methods (e.g video and interactive tools). We need to build prototypes of these ideas. We also need to consider ideas like Doyen, Sage, Scientific Linux, and Knoppix Math (a Japanese effort). In the short term the idea is to choose tools which achieve certain goals (e.g. noweb for textual literate programming), modified as necessary to fit new ideas. Some of these tools are packaged along with the axiom distribution in the zips directory. Everything in the repository outside of zips (and some inside of zips) is part of the commercial axiom build or later developments. GCL even has other systems packaged within it. These short term tools have been the source of controversy for various reaons. Axiom is not yet ansi common lisp but aspires to that goal, at which point it should run in any common lisp rather than just GCL. However, GCL was historically developed specifically for Axiom by Bill Schelter under contract to IBM. I worked with Bill on various aspects of GCL, thus making it rather easy as a first target port. In the long term the GCL bundle should assume the status of "just another ansi common lisp". Axiom used to run on about a dozen common lisps so it is nearly ported except for ansi changes Noweb was chosen as an initial literate programming tool and axiom was completely rewritten to make every source file (almost) into a trivial case of a literate file. There has been some controvery over what the long term format of Axiom will be, spread among things like ALLPROSE, straight latex, noweb, a lisp-based noweb, etc. All of these are "tactical" discussions rather than long term "strategic" discussions. Part of the difficulty in our discussions is that we are often arguing from different starting points. I tend to start from the philosophy and work "top down" and insist that the ideas should shape the tools, Some others tend to start with the tool and work "bottom up", insisting that the tools should shape the ideas. The results lie somewhere in between. Running code tends to determine the actual result. Tim _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer