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

[Waldek Hebisch]

Bill Page wrote:
> On April 26, 2007 10:51 PM Waldek Hebisch wrote:
> > 
> > Bill Page wrote:
> > ...
> > > 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.
> 
> Do you mean that it is intended to protect the repository from
> commits by Windows developers of source code containing Windows
> line endings? I suppose. I never thought of it that way before.
> 

My point was that the the current setting is intended to work
for Windows developers -- if it causes problem we can change it.
We could try setting svn:eol-style to LF or remove this property.  
But we should check first if this gives desired consequences.
BTW:  Same files have no svn:eol-style property on them, are
they transferred as is?

> But as a "Windows developer" I only consider it a pain that SVN
> corrupts the linux sources in this manner. If I check-out code
> from a "linux" project, I expect it to be valid linux source.
> And the "corruption" can be subtle, for example the format of
> the Axiom database files look like text files but contains byte
> offsets encoded as text. These offsets are wrong if the line
> endings are changed by SVN.
> 

AFAICS there are no properties on database files -- were they
corrupted?

> Windows porting tools like MSYS and the cygwin linux emulation
> environment assume that source files will have unix line endings.
> Even most native Windows text editors support unix line endings
> as an option.
>

svn should allow user control of line convertion but the documentation
leaves impression that the settings are hardwired.  I consider this
as a design (or maybe documentation) bug.  MSYS and cygwin svn
are runninig in Unix environment so should use Unix line conventions.
 
> > 
> > > > 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.
> >  
> 
> Braces like { } in the Makefile caused the make to fail.
> Replacing these with ( ) worked. I have not encountered this
> problem before.
> 
> I have
> 
> $ make --version
> GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
> 
> Perhaps I need to upgrade it?
> 

Could you say what is the error message and post corresponding fragment
of the build log.  The log should contain (rather longish) shell
command.  If this command is garbled, then we have make problem.
Othewise it may be some shell weirdness.

> > ... 
> > 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.  
> 
> After reading the Common Lisp documentation here:
> 
> http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_1130.html
> 
> It is not clear to me how I could specify something like
> 
>   C:/msys/1.0
> 
> to be added to a pathname by this method. How can I expect GCL
> to know this BASE component of native Windows paths when called
> from which an MSYS build environment?
>

Ansi Lisp has no concept of current directory, so is of no help here
(and almost anyting about files is implementation dependent anyway).
But I think that I have reasonable solution, just the solution
depends on implementation.  For clisp, cmucl, gcl and sbcl the following
works:

(merge-pathnames "$@" (truename ""))

But Poplog clisp needs:

(merge-pathnames "$@" (truename "."))

which works incorrectly in gcl, and gives error in clisp and other
implementations may need something entirely different.

So, the full solution to relative name problem will be too large
for Makefile -- we should put it in separate portability library.
 

-- 
                              Waldek Hebisch
address@hidden