[Axiom-developer] Build machinery -- support for out of source build

[daly]

Clearly you don't see that a compromise is worth attempting.
That's fine. It was just a suggestion.




> The argument that 'by design the "src" tree should never be
> touched by Make so you should be able to mount the source read-only
> and type Make' is inherently bogus. "src", "obj" and friends
> are created *within* the Axiom source tree.

Ok. I guess I wasn't clear enough. Let me try again.
Suppose the src tree is in /home/daly/axiom
and you would like the build to be in /home/gaby.
I believe it is sufficient to type

  cd /home/daly/axiom
  export AXIOM=`pwd`/mnt/linux
  make INT=/home/gaby/int OBJ=/home/gaby/obj/linux MNT=/home/gaby/mnt/linux

although I've never tried it. Once the current build/test cycle completes
I'll try it. It is an interesting experiment and should uncover some 
simple bugs, I'm sure. However, the design calls for the construction of 

  /home/gaby/int
  /home/gaby/obj/linux
  /home/gaby/mnt/linux

which, as I understand it, is an out-of-source build. There will 
certainly be bugs. But the system should work by design. I'll try
it, fix the bugs, and put this issue to rest.




* Minimize work

> In build-improvements, the dependency is slightly more
> complicated because I have added a full bootstrap in three stages.

That's fine but uninteresting. The goal of making autoconf work in
silver has nothing to do with your boot improvements. Those should
be independent changesets.




> The argument that "int/" speeds up the build process is almost
> fallacious.

I listed 5 ways that "int" speeds up the build process. Why don't those
ways speed up the build? The "int" directory cache doesn't speed up
the build the first time but it doesn't slow it down either. However,
the second build is much, much faster if you retain the cache.

You could argue that the files in "int" and the files in "obj" could
be merged into a single directory with the same speedup result. That
is true in terms of speed. However you lose one major ability when
you merge int and obj. Suppose that we want to build Axiom on several
different platforms, e.g. fedora, debian, ubuntu, solaris, and other
systems that might exist in a compile farm. In the current split the
  
   int directory contains system-independent, machine-generated files
   obj directory contains system-dependent, machine-generated files

so you can
  
  1) do a complete build on one system
    for each different system do:
      2) copy the whole axiom tree to the next system
      3) rm -rf obj mnt
      4) set the AXIOM variable
      5) make

and you get a whole new Axiom for the second system but you never
need run boot, you don't have to run noweave, you need only run
latex once, and you don't have to do the algebra compiles. Seems
like a HUGE saving of time to me. Since we do not yet have a
compile farm this facility isn't heavily used outside my home.

I'm not sure how you might do this if int and obj are merged.



You clearly have a different idea of how autoconf should structure
system builds in silver. That's fine. I'm simply pointing out that
the current build system has features which most people do not 
understand. We can recreate these features in the new build system
after the diff-Naur merge completes if we find them useful.


Tim