RE: [Axiom-developer] RE: algebra Makefiles with explicitdependencies, bootstrap, fixed-points etc.

[Bill Page]

Steve, tim,

On Monday, January 10, 2005 4:43 PM you wrote:
> ...
> I built a fresh system with updated bootstrap code. This is the
> code generated by the fixed point build.
> 
> The fixedPoint script identifies RECLOS and ROIRC among the
> domains which change after the second iteration of the fixed
> point build. These are the _only_ domains which achieve the
> second iteration form with the updated bootstrap code (after a
> single pass). All other domains are built in exactly the same
> way.

You mean the others are built in the same way, with errors? This
might mean that even with corrected bootstrap files, the Axiom
spad code needs two iterations to achieve a fixed point. If so
this would imply that mutual recursion is already an essential
part of the build. I think that this is plausible and quite
fascinating ...

The list of dependencies for RECLOS is

RECLOS.o:RECLOS.spad RCFIELD.o CHARZ.o RING.o RNG.o ABELGRP.o
  CABMON.o ABELMON.o ABELSG.o SETCAT.o BASTYPE.o KOERCE.o SGROUP.o
  MONOID.o LMODULE.o ORDRING.o OAGROUP.o OCAMON.o OAMON.o OASGP.o
  ORDSET.o COMRING.o BMODULE.o RMODULE.o FIELD.o EUCDOM.o PID.o
  GCDDOM.o INTDOM.o ALGEBRA.o MODULE.o ENTIRER.o UFD.o DIVRING.o
  FRETRCT.o RETRACT.o RADCAT.o REAL.o KONVERT.o PI.o NNI.o INT.o
  SYMBOL.o REF.o ALIST.o LIST.o STRING.o CHAR.o SINT.o OUTFORM.o
  PRIMARR.o A1AGG.o ISTRING.o SRAGG.o FLAGG.o LNAGG.o INS.o OINTDOM.o
  DIFRING.o LINEXP.o PATMAB.o CFCAT.o STEP.o ILIST.o LSAGG.o STAGG.o
  ELAGG.o URAGG.o RCAGG.o IXAGG.o CLAGG.o HOAGG.o ORDSET.o AGG.o
  ELTAGG.o SETCAT.o BASTYPE.o LSAGG.o STAGG.o URAGG.o RCAGG.o HOAGG.o
  AGG.o TYPE.o EVALAB.o IEVALAB.o LNAGG.o IXAGG.o ELTAGG.o ELTAB.o
  CLAGG.o FLAGG.o ELAGG.o OM.o INS.o EUCDOM.o UFD.o GCDDOM.o INTDOM.o
  ALGEBRA.o DIFRING.o ORDRING.o MODULE.o RING.o ABELGRP.o ABELMON.o
  MONOID.o BOOLEAN.o QFCAT.o FEVALAB.o DIFEXT.o PDRING.o FLINEXP.o
  PATAB.o FPATMAB.o CHARNZ.o PFECAT.o

It clearly depends on many of the bootstrap files. And ROIRC needs

ROIRC.o: ROIRC.spad RRCC.o SETCAT.o BASTYPE.o KOERCE.o ORDRING.o
   OAGROUP.o OCAMON.o OAMON.o OASGP.o ORDSET.o ABELMON.o ABELSG.o
   CABMON.o ABELGRP.o RING.o RNG.o SGROUP.o MONOID.o LMODULE.o
   FIELD.o EUCDOM.o PID.o GCDDOM.o INTDOM.o COMRING.o BMODULE.o
   RMODULE.o ALGEBRA.o MODULE.o ENTIRER.o UFD.o DIVRING.o UPOLYC.o
   POLYCAT.o PDRING.o FAMR.o AMR.o CHARZ.o CHARNZ.o FRETRCT.o RETRACT.o
   EVALAB.o IEVALAB.o FLINEXP.o LINEXP.o KONVERT.o PATMAB.o PFECAT.o
   ELTAB.o DIFRING.o DIFEXT.o STEP.o NNI.o INT.o LIST.o LSAGG.o
   STAGG.o URAGG.o RCAGG.o HOAGG.o AGG.o TYPE.o LNAGG.o IXAGG.o
   ELTAGG.o CLAGG.o FLAGG.o ELAGG.o OM.o ILIST.o MONOID.o PI.o
   BOOLEAN.o INS.o OINTDOM.o CFCAT.o REAL.o

It similarly depends directly on many bootstrap files. Note that
they both depend on EUCDOM.o that you mention below as missing
from the bootstrap.

But for example another file that shows up in the fixedPoint list
as changing, D01AGNT, does not depend on EUCDOM.o and on fewer of
the bootstrap files

D01AGNT.o: D01AGNT.spad INT.o LIST.o ILIST.o LSAGG.o STAGG.o
  URAGG.o RCAGG.o HOAGG.o AGG.o TYPE.o SETCAT.o BASTYPE.o KOERCE.o
  EVALAB.o IEVALAB.o LNAGG.o IXAGG.o ELTAGG.o ELTAB.o CLAGG.o
  KONVERT.o FLAGG.o ORDSET.o ELAGG.o OM.o NNI.o STRING.o CHAR.o
  SINT.o OUTFORM.o PRIMARR.o A1AGG.o ISTRING.o LSAGG.o STAGG.o
  FPS.o RNS.o FIELD.o EUCDOM.o PID.o GCDDOM.o INTDOM.o COMRING.o
  RING.o RNG.o ABELGRP.o CABMON.o ABELMON.o ABELSG.o SGROUP.o
  MONOID.o LMODULE.o BMODULE.o RMODULE.o ALGEBRA.o MODULE.o
  ENTIRER.o UFD.o DIVRING.o ORDRING.o OAGROUP.o OCAMON.o OAMON.o
  OASGP.o REAL.o RETRACT.o RADCAT.o PATMAB.o CHARZ.o DFLOAT.o
  DIFRING.o TRANFUN.o TRIGCAT.o ATRIG.o HYPCAT.o AHYP.o ELEMFUN.o
  ELAGG.o FLAGG.o FS.o ES.o PATAB.o FPATMAB.o FRETRCT.o GROUP.o
  PDRING.o FLINEXP.o LINEXP.o CHARNZ.o INS.o OINTDOM.o CFCAT.o
  STEP.o QFCAT.o FEVALAB.o DIFEXT.o PFECAT.o BOOLEAN.o 

If the bootstrap files and the database files have been updated
but D01AGNT still changes then it must be from some other cyclic
dependency.

> Tonight, I will run a second iteration build to see if the
> previous `fixed point' which we arrived at has changed.
> 
> With the fixedPoint script, I noticed that the old database
> directories, DEPENDENTS.DAASE and USERS.DAASE, under int/algebra,
> are not removed in preparation for the second iteration. Am
> I mistaken in thinking that this will influence the subsequent
> compilation?

You are correct. The src/algebra/Makefile.pamphlet that I am using
on the axiom--windows--1 branch has been updated to properly rebuild
the databases if any of the *.NRLIBS/code.o files change. In the
linux branches (e.g. axiom--main--1) the database build is still
done via a kludge that requires you to delete the file called
`dbcomplete' in order to force a rebuild. Alternately you could
also delete the int/*.spad files which will force them to be
re-extracted from the pamphlet files and also trigger deletion of
the dbcomplete file.

> It is the only thing I can think of which might explain why the
> build with the new bootstrap code is so dissimilar to the second-
> iteration fixedPoint build.

The databases that are used for the initial build are definitely
out of date and differ from the newly generated database by a few
bytes (more or less). For the fixedPoint interation the five new
database files should be copied back to the src/share/algebra
directory in preparation for the next iteration.

> 
> I have not had much time, but I did briefly look at a few
> domain vectors which are now generated under this new build.
> Here I see differences which were not present in the other two
> builds. Things have changed in a subtle way. I hope to find
> the time over the next few days to examine these changes more
> throughly.
> 
> 
> Let me summarize what I've noticed as being problematic in
> the old bootstrap code:
> 
>   SINT is missing a definition for `one?'.
>   EUCDOM- is missing a definition for `expressIdealMember'.
>   TSETCAT- is missing entirely.
> 
> I would be pleasantly surprised if this list is complete.

It is not so clear to me why the build appears to succeed
even though these definitions are missing. In other languages
I would presume that this situation would be easily caught
as a missing file during `linking'. But here we have this
"domain vector" thing. Is there not some why that the
compilation could be made more robust by verifying the
domain vector at compile time?

This question probably displays my ignorance of exactly how the
Axiom compile works. If either you or Tim could explain to me
why this error is not detected I would be most appreciative.

> 
> I'll try an pull more information together to help better
> understand what is happening, and why.
> 

Thanks.

Bill Page.