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

[Waldek Hebisch]

Bill Page wrote:
> 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). 
> 

No, AFAICS differences are due to trailing spaces -- actually it
seems that we have hundreds of lines with trailing whitespece
while IMHO such lines should be extremally rare (that is all
useless trailing whitespece should be stripped).

> 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. 
> 

This setting is intended as a convenience for Windows developers...
And it seems to work -- at least it seems that the repository
is free from unwanted carriage returns.

> > 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. 
>

I appreciate advantages of subshells.  But on some platforms
(including Windows) subshells are rather slow to create, so
we probably want to avoid them in performance critical parts.

The shell code in question is _not_ performance critical, but
since the only change to src/algebra/Makefile.pamphlet I see 
(or did I overlook something?) is introduction of subshells
I would like to know if there is a special problem here that
braces have but subshells avoid.
 
> > 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

No.  Extraction from pamphlets is a different problem.

> >    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. 
>

I am specifically referring to:

 $(addsuffix .$(FASLEXT), $(IN_from_MID)): \
     %.$(FASLEXT) : $(MID)/%.clisp
-       @ echo 10 making $@ from $<
-       @ ( B=`pwd`;\
+       @ echo 10a making $@ from $< # hack 1 by Bill Page
+       # avoid paths in file names for Windows compatibility

(and the hack 2).  The `pwd` command I put there is already a hack
to work around fact that meaning of relative :output parameter to
compile-file is implementation dependent.  In principle using

:output (merge-pathnames "$@") 

should help but I still had problems after doing that, so
I used `pwd` as temporary hack before I get :output working
in consistent way.  

But if using separate directory here causes extra problems, 
I think that we can just put all .clisp in single directory.
 
> >    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?
> 

Above I used wrong words.  Given problem $(BASE) is a logical
solution.  Your 'cd'  + 'notdir' + 'mv' combination is also a
logical solution, if we _have to_ keep current files loctions.
But it is getting heavy, and we may put .clisp files in current
directory which should solve problem in 'IN_from_MID' rule
and simplify solution to 'AUTO_from_MID' rule

> > 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. 
> 

I am trying to avoid unnecessary differences.  But IMHO global
variables (even unused ones) significantly increase complexity and
consequently we should limit use of them.  In particular
I think that we should decide at merge time if we really
want the variables in question.  Of course the problem may
solve itself earlier: the variables may turn out to be
usefull ones.  But ATM the difference is to remind us about
the problem.

> >   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. 
> 

Please do.  I would probably first add no new variables and
then look which new variables are used by the rest of the patch and
which exisiting values changed.


-- 
                              Waldek Hebisch
address@hidden