> > For me personally, autoconf support is more important than > > almost everything else, the reason being that I would really > > like to see more Axiom developers. The more standard our build > > environment is, the easier that will be. Seconly increasing > > the number of type of supported platforms is very important > > for increasing the number of Axiom users. > > > > So I am especially interested in what I labelled Gold (52) > > above, but I can live with the experimental branch until > > then. > > I realize that autoconf is your golden standard and you know I believe > that it won't have a measureable effect on the number of developers. >
Tim, ATM you can count 1 (that is me) -- compared to 8 it looks measurable. Before Gaby effort I was consider doing my own fork or forgeting about Axiom at all. > I do think the build-improvements branch has a positive effect by > making people believe they can change the system. Unfortunately > changing Axiom is easy but showing that you didn't break anything is > hard. A lot of my changes are not posted because there are many > things to check. Though I have a lot of experience with Axiom I > cannot answer Gaby's questions without study and experiment. I don't > think autoconf is going to change that. > I think Tim you do not understand one issue: human labour is expensive and unreliable -- computers are cheap and can do repetitve work with high reliablity. Autoconf is just a tool, big thing is having autmated build and testing process. ATM Axiom is _extremally_ buggy, requireing a lot of hand work to build and test. Also, Axiom contains a lot of junk which at best takes extra storage and frequently causes confusion. Your policy of slow changes means that bugs are not fixed, but still does not prevent breakage (at least one change from 2003 breaks automatic generation of .pht files, and changes to Axiom book probably interfere with automatic generation of .ht files). On more practical ground: I have access to 70 machines on which I could test Axiom, but using more machines for silver/gold is useless since building "out of the box" fails on most of them (I sent a report recently, so you can see the problem). Using build-improvements I have problem only on one machine -- see part about 'msgfmt' in http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00750.html On other machine build-improvements builds without problems, and with very little manual effort. Gold/silver in rare cases when they "just work" still require much more typing. And when something gets broken it is easier to apply quick fix to build-improvements then to gold/silver. -- Waldek Hebisch [EMAIL PROTECTED] _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
