axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] algebra Makefiles with explicit dependencies, bootstra


From: Bill Page
Subject: [Axiom-developer] algebra Makefiles with explicit dependencies, bootstrap, fixed-points etc.
Date: Mon, 3 Jan 2005 16:39:12 -0500

Tim,

You wrote:
> 
> Bill Page wrote:
> > Also, although I have not committed any changes for this yet,
> > I have also been working on adding the missing dependencies in
> > the algebra/Makefile. 
> 
> This isn't going to work which is why I left the dependencies
> blank. There is a subtle reason why this fails which escapes me
> at the moment.
> 

Well, it is working for me so far. But of course there are still
limitations. There are many cyclical dependencies of course and when
presented with these 'make' breaks the cycles somewhat arbitrarily
by ignoring some of the links. But this is no real consequence for
the build as long as we continue to attempt to compile the algebra
files in layers as we do now. Missing these links will cause some
changes of files to be ignored by 'make'. But this is unavoidable.

These cyclical dependencies where the reason for the bootstrap design
in the first place.

Better than just implementing the dependencies would be to fully extend
the bootstrap approach to all spad files.  They should all exist is two
forms - a bootstrap lisp form and the spad form. Then the build could
proceed by first building all the .o files from the lisp bootstrap.
With this "bootstrap system", one must compile all the spad files.
Then compare (diff) the resulting *.NRLIB/code.lsp files with the
bootstrap lisp. If there is a difference the bootstrap lisp code must
be updated, and then the spad re-compiled again. This process should be
repeated until a fixed-point is reached where the bootstrap lisp code is
the same as the generated code.

As far as I know, finding such fixed-point solutions is the only way
to deal with a system of dependencies with cycles.

Regards,
Bill Page.





reply via email to

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