[Axiom-developer] Re: building wh-sandbox on Windows

[Bill Page]

Quoting Waldek Hebisch:

> Congratulations.  Few quick remarks about the diff:
>
> 1) It does not apply cleanly to 515 (I had problem with
>    README.build-improvements, configure.ac.pamphlet and
>    src/interp/sys-pkg.lisp.pamphlet)
> 2) Some parts seem to be whitespace-only diff (differnces
>    in whitespace probably are responsible for failures in 1)

Perhaps one cause of the apparent whitespace differences
has to do with the annoyance of different line endings between
Linux and Windows. SVN for Windows automatically terminates
lines with CR+LF, but the MSYS tools assume normal Unix
convention of just newline (LF). 

I would prefer if we set the EOL attributes on the SourceForge
SVN repository so that SVN does not mangle line endings
in this way. But this is just an inconvenient a fact-of-life for
Windows developers. Most Windows and MSYS tools are
tolerant for these differences but some are not. When I
produced the patch file I sent you, I filtered it by tr -d '\r' to
convert back to Unix line endings. 

A significant thing to remember about MSYS is that it is really
a cross-compilation/porting environment intended to produce
native Windows applications from Unix-oriented sources. It is
not quite a native development environment for Windows (like
Visual C, for example). 

> 3) Use of '(in-package \"boottran\")' in document.in is wrong,
>    because in Ansi Lisp the package name here is case sensitive,
>    so we want '(in-package \"BOOTTRAN\")'

Ok. BTW, the build I did of wh-sandbox on Windows was using
the ANSI mode of GCL. I have compiled the same sources under
Linux using CLtL1. Thank you very much for resolving the
differences that make it possible to use GCL in ANSI mode. 
I did not realize that it would also be possible to use a dialect
of GCL that was compatible with *both*. This is a nice feature to
try to retain at least during the transition to full ANSI compliance. 

> 4) Do you really need subshells in
>          src/algebra/Makefile.pamphlet?

Subshells make it easier to make local changes to the current
directory to avoid some path issues. But, no they are probably
not needed in a more careful design. 

> 5) In src/interp/patches.lisp.pamphlet the first hunk inroduces
>    conditionals for |$saturn| etc.  I prefer to set those
>    variables unconditionally, because ATM there is _no_    platform 
> on which choosing Saturn works. 

Ok. I am in favour of eliminating as much of this cruft as
possible (before we start adding more of our own ;). 

> 6) We can avoid using pathnames during interpreter build
>    by eliminationg int/interp subdirectory -- one reason for
>    keeping this directory is that we want sane pathname
>    handling at user level, so have to solve the underlying
>    problem. 

I am not sure if I understand what you call the "underlying
problem". Do you mean the fact that Axiom's pamphlet
files group code into "chunks" that may not correspond to
files at the lowest level? I suppose the model that we want
to present to the user is: "Axiom's source code as a set
of literate documents...". How these documents are woven
from text and code chunks is (mostly) our problem. But
what the build machinery needs is the chunks of various
pamphlets organized into files. I worry that the tools we
have for doing this right now (e.g. noweb, make stanzas,
and even awk scripts) are a little too primitive. 

>    The same solution should work for build. 

Again, I am not sure exactly sure to what "solution" you
are referring, but if you mean continuing the use of an
intermediate file system-oriented view of the source code,
then I suppose that right now we have no other option. 

>    But if we have to use gross hacks to get around build
>    problems then I prefer to move files to single directory. 

I don't view the introduction of a "BASE" variable as a gross
hack. But this is different than what I did in two cases marked
"hack #1 billpage in the Makefile.pamphlet source. In that
case I made use of the intermediate directory as a temporary
staging area for both the input and output files. A 'cd' to change
the current directory eliminates one absolute path and the use
of a 'mv' command moves the other path out of the native
environment (Windows) and back into the development
environment (MSYS). But as you say this could have been
handled by the use of $(BASE) instead. So can I assume
that you would be in favor of the latter option?

> 7) In config/var-def.mk I ommited a few unused variables
>    that Gaby added -- I feel that we should not slavishy
>    copy the bloat created by autotools.  More preciesly,
>    I do not like bloat in machine generated files but as
>    long as thing are handled automatically such bloat is
>    acceptable.  But we are maintaning var-def.mk by
>    hand and bloat is a problem. 

I understand your point. What I tried to do was to use
'svn merge' just to pull as much as possible an entire
revision from build-improvements into wh-sandbox. My
thinking was that this might prevent problems in the future
in the case of an eventual merge of both build-improvements
and wh-sandbox back into the "Axiom Silver" trunk. But
where we are going with this is not clear to me yet. 

>   So I would like to have only usefull stuff in config/var-def.mk
>    -- it looks that your patch copies a bunch of unused
>     variables from build-improvements. 

That is correct. I think there are advantages and disadvantages
of either choice. In favor of retaining the unused (but "standard")
autoconf variables is in the eventual move to a complete
automated make environment. (I think that was Gaby's original
intent.) In which case, as you say, this complexity would be
hidden by the machinery. The question is then: how much of
this can we tolerate now? Maybe the answer is different
between build-improvements and wh-sandbox... For now I will
try to eliminate the unused variables in my patch wh-sandbox,
but doing so requires a little more analysis. 

> 8) Concerning BASE variable: it does not look nice, but
>    I do not think that other solutions would look better. 

I agree. If we can afford the divergence of the code between
wh-sandbox and build-improvements then it makes sense
to experiment with two rather opposite solutions to the same
problem. 

Regards,
Bill Page.