"Page, Bill" <[EMAIL PROTECTED]> writes: | Gaby, | | On Thursday, August 10, 2006 9:29 PM you wrote: | > ... | > A project might be to have the compiler output spad | > dependencies -- | > just like GCC is able to output dependencies, which greatly | > facilitates the tedious part of writing Makefiles and | > keeping them in sync; Automake uses it. | > | | Where you here "years ago" when we first discussed the fact | that Axiom's build dependencies form a digraph with loops?
I was probably not here; or I was here but not paying attention. :-/ | That makes the problem of using Automake rather more | difficult, I think - not impossible, but one would still | have to manually define a set of "bootstrap" modules which | when removed from the graph, turn it into a lattice that | can be sorted. I don't expect to have Automake figure out the dependencies by itself. However, I do expect that at some point, Axiom compiler should be able to output the dependencies. It may not be a simple task; but that is the whole point! | Tim Daly did this entirely manually as part | of the initial steps in making Axiom available as open source. yes; I understand that. That must have taken him a good deal of resources. | Prior to that it was always necessary to have a running | version of Axiom in order to build Axiom - and that was | considered by some people contrary to the intention of making | Axiom "fully available" as open source (i.e. without also | having to distribute a binary version). | | Having software find a optimal minimal set of bootstrap | modules is an interest (open?) question. It is an ideal. If we can't get it 100%, we must approximate to the point where the residual is sufficiently small and manageable. | What to actually do about the circular dependencies themselves | is, perhaps a separate, but interesting subject in it's own | right. | | I am very interested in you opinions on this subject because | of your background with gcc which also involves a bootstrapping | process, although I think no circular dependencies, right? Bootstrapping problems, by definition, involve circularities. GCC, for example, provides a sufficiently ANSI C89-conformant compiler. It is written in C. Therefore we have a bootstrapping problem. "Fortunately", there are many flavours of C. K&R being the most popular. Well, you have to define which "K&R". Consequently, GCC was written in K&R C, restricted or augmented as appropriate. But, the new stream of developers had ANSI C89 background, and very few knew the subtle differences between K&R and ANSI C. And even the experts that knew them got trapped from time to time. The result was hard-to-find miscompilation bugs. Consequently, we decided to bit the bullet and require ANSI C89 bootstrapping compiler. For the few remaining platforms (notably some old HPUX) where the system compiler is not ANSI C89, there are binaries people can download install. The project I know that is close to Axiom's dilemma is the Glorious Glasgow Haskell Compiler System (GHC). GHC is written in Haskell and you need a Haskell compiler to bootstrap it. To facilitate porting to new platforms, they also problem generated C files that people to compile with "C" to build a boostrapping compiler. They also distribute binaries. Where we are now is a bit different from where Tim was four years ago. We have to think about how to reduce the surface complexity (as would say a friend of mine). We're not going to attract lot of people because we try to make Axiom look complicated. We can gain by making it look simpler to use, simpler to understand, simpler to modify. -- Gaby _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
