[Top][All Lists]

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

RE: [Axiom-developer] RE: algebra Makefiles with explicit dependencies,

From: Bill Page
Subject: RE: [Axiom-developer] RE: algebra Makefiles with explicit dependencies, bootstrap, fixed-points etc.
Date: Sun, 9 Jan 2005 21:40:39 -0500


On Sunday, January 09, 2005 5:09 PM you wrote:
> I don't think we need to rush ahead with this task as it
> is much more important to make sure it is right than it is
> to do it quickly.

I agree that it is important to make sure that it is right.
In fact that is why I started to look at this. I was worried
that the current build does not (quite) do it right. The
fact that the generated lisp files change after an iteration
of the build proves that, I think. So on the contrary I do
think there is some urgency.

> I'd suggest that the "fixed-point" bootstrap be merged into 
> axiom--algebra--1 so we can test it first.

I am a little confused by the large number of axiom branches.
Can you remind me what is axiom--algebra--1? How does the code
in this branch compare to the current axiom--main--1 and
axiom--windows--1? Steve also mentioned axiom--language--1.
What is that? I see the titles at
but shouldn't we have a more complete discription somewhere
of the goals of each project, a list of who is working on
them? Someone names as the "owner" etc.?

By "fixed-point bootstrap" do you mean the bash script that
I called fixedPoint which performs the iteration or the actual
bootstrap lisp files that result from this iteration? If it
is the former, then that just involves 3 very simple scripts
that call 'make' - no changes at all to the Axiom code - but
the Axiom algebra spad code must be built at least twice in
order to obtain consistent lisp code that is consistent with
the spad files.

If you mean the the bootstrap lisp files, then we know that
if we replace the 80+ <<*.lsp BOOTSTRAP>> code chunks with
updated lisp code, then the generated lisp code will be
consistent with the spad files on the first build.

> By test it I mean that we have to compare, line by line, the
> output of the current input files to see if anything breaks.
> There are also a set of known broken input files
> (see src/input/Makefile.pamphlet) and we need to see if this
> fixes any known problems there.

That should be pretty easy since we already save the output as
.output files. I think we just need to cache the first version
of these files somewhere and then delete them and re-run 'make'
to create a new set. Then run a diff. I will do this later
tonight with my current axiom--windows--1 build and let you
know the result.

> I don't believe that the build should modify the 
> src/algebra/*.pamphlet files automatically. The source
> directory is generally considered read-only, hand-generated
> code. It might be the case that the build system CHECKS to
> see if there is a difference between the bootstrap files
> and the build files.

I think it is *essential* that the build system CHECKS to see
if there is a difference between the bootstrap files and the
build files. In fact that is *exactly* what the fixedPoint script
does now. We already know that if we do not replace the original
bootstrap files, then there are differences at both the initial
build and the first iteration.

> It is more important to understand the nature of the difference
> and what causes it. These differences could be showing up at
> higher levels but not apparent because we have not kept the
> generated .lsp files from prior builds.

The fixedPoint script keeps the generated .lsp files from the
previous build and compares them to the newly generated .lsp
files. It repeats the build until all of the files are the same.

> We certainly do not want to break the february build with
> such a fundamental change.

My conclusion is that the current build is already subtly broken
and we probably do not want to release a february build *until*
we fix this problem. The simplist way to fix the problem is to
replace the current bootstrap lsp code in the pamphlet files
with the lsp code generated by the fixedPoint iteration.

> The february build will be the first "real axiom" version for
> most people and it is important that it run properly.

I agree. That is the reason why I think it is quite urgent that
we resolve the current problem first.

> There are several hundred people at least looking at axiom
> (given the download numbers) so we have a responsibility to
> make sure that our changes are correct, complete, and necessary.

You are right, but I think your estimate of the number of people
currently looking at Axiom is too small by about a factor of 10.

Bill Page.

reply via email to

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