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

[Bill Page]

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.

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.

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.

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

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

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

Ok, I will try.
 

> ...

Regards,
Bill Page.