Re: [Reduce-algebra-developers] problem building reduce.img

[Arthur N. <ac...@ca...>]

On Sun, 2 Oct 2011, Aditya Narayan wrote:
> I tried to build the reduce.img for the embedded reduce using the following:

> cd csl/embedded
> ./reduce -w -z -Dno_init_file ../cslbase/buildreduce.lsp -D@srcdir=../cslbase
> \ -o reduce.img
> The result is that it builds a file that's only 278k big. And exactly the
> same happens on both MacOS X and Linux:


Apologies. So there are two parts to my answer.

Firstly the embedded sub-directory contains a snapshot of all the files 
from cslbase, so does not automatically get updated as csl does. I needed 
to update fns2.c to add an nreverse2 function... but after a while I had 
made a new-embedded directory that tries a little harder to be robust. In 
fact it was not and I had to fix something there too. I hope I have 
checked in a new version....

OK first re new-embedded. The main system used GNU autoconf (ie a 
"configure" script) to adapt to the machine being used. That has 
advantages but is messy and complicated and slow. The "embedded" directory 
sidesteps this two ways. First it tries to use only conservative C code. 
Secondly it provides a hand-crafted "config.h" file. I had added a 
BUILTFOR predefined to the main config.h that lets one report something 
about the current system. I had not put that in the hand-crafted config.h. 
I have now! In general the "embedded" and "new-embedded" are for people 
who will be looking hard at the C code so they can extend it or use it ion 
an odd way - they may then wish to look at config.h from time to to time 
to adapt it to the platform that natters most to them. And then MAYBE look 
at "#ifndef EMBEDDED" line in the main csl/cslbase sources if they wish to 
re-activate something I disabled in the name of simple portability...

OK now back to embedded and why it was so delicate that I invented 
new-embedded. The CSL Reduce compiles some stuff from Reduce/Lisp into C 
to make files u01.c, u01.lsp etc. Actually embedded sort of expected that 
you made a full Reduce image using an up to date non-embedded system, then 
copied cslbuild/generated-c/u*.c to csl/embedded and then build the reduce 
executable there. As building the "full" system changes things the u*.c 
and u*.lsp files RAPIDLY get out of step. So to mend the build I went
    cd .../trunk
    cp cslbuild/generated-c/u*.c csl/embedded
(after I had build a "real" Reduce so that the files in generated-c has 
been updated properly).  The bad news is that if you try to build a 
reduce.img using the embedded version of reduce as per your attempt it 
used u*.c from csl/embedded and u*.lsp from cslbuild/generated-c and when 
they are not in step (ha ha) the compilation failes. You may see traces of 
that if you review a log of trying to build reduce.img that way.

Now more about embedded vs. new-embedded. To reduce delicacy, I have made 
the new-embedded version not use anything compiled into C. I have also 
provided samples there showing how to make a "mini" image as well as a 
"full" one, since people using Reduce embedded in any sense are liable to 
want to customise stuff. This makes new-embedded a bit slower. So that is 
maybe enough cause for me not to delete the old embedded. But I am *NOT* 
doing heavy maitenance on the files in "embedded". If you use it then 
please compare all C sources files with the ones in csl/cslbase in case 
there are updates that newer version of the Reduce sources rely on.... it 
is for "experts"!!!!

Hope this lengthy explanation gives enough elaboration that you can move 
forwards happily.
             Arthur