[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] RE: algebra Makefiles with explicitdependencies, b

From: Stephen Wilson
Subject: Re: [Axiom-developer] RE: algebra Makefiles with explicitdependencies, bootstrap, fixed-points etc.
Date: Sun, 9 Jan 2005 16:18:23 -0500
User-agent: Mutt/1.5.6+20040907i


I figured the odds were good that we would agree on updating the
bootstrap code. I have about 37 (out of 85) more files to update. I
have discovered another problem in the bootstrap code so far: EUCDOM
is missing the code for expressIdealMember.

On Sun, Jan 09, 2005 at 03:14:44PM -0500, Bill Page wrote:
> I don't think there would be much point in automating this
> separately from the issue of implementing a general "fixed
> point" build process. 

Given that we may need to work with the current build configuration
for some time, I figured automating the process of writing out fresh
bootstrap code might be a plausible, lightweight, solution for
now. The `by hand' method has the virtue of forcing one to pay
attention, yet is error prone by its nature. It will take some testing
for me to be convinced that the updates I am doing now are not
introducing any new bugs. Conversely, it would take some testing for
me to be confident some custom build tool was doing its job. 

> I think you should go ahead and do this and update the
> axiom--main--1 branch. I can grab your changes from there and apply
> them to the axiom--windows--1 branch.

I would prefer to get the changes written, then package up a set of
patches to distribute to yourself and Tim. You guys have about a
gazillion times more experience testing a freshly built system then I
do ( of course, I will do a build-test cycle as well ). I'll update the
language branch, but until I'm more seasoned I'd prefer to regard
main as `hands off'. 

> But lets keep in mind that this is not a general solution. It
> only solves the build problem and retains the current make process
> for now. I think we should continue to pursue the idea of mutual
> recursion in Axiom since it is (at least implicitly) such an
> essential part of the current Axiom library.

I agree. For myself at least, learning how things are done today can
only help in realizing what we want to achieve down the road. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]