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

[Bill Page]

On April 28, 2007 5:11 PM Waldek Hebisch wrote:
> 
> Gabriel Dos Reis wrote:
> > Having read this thread many times, it appears to me
> > that the whole thread is confused.
> > 

I agree.

> > First, I think people should state clearly and
> > unambigously what is the problem they are trying to
> > solve.
> > 
> > Second, people should state very clearly what is the
> > problem they are trying to avoid with relative paths.
> > 
> 
> If you missed it we are trying to solve the following
> exercise:
> 
> Given make variables $< and $@ write a make rule which
> compiles Lisp file from $< and puts the results in address@hidden
> 

>From my point of view, I do not think that completely
describes the problem - at least not the problem that
we need to solve in the Windows build of wh-sandbox.

> You can easily check that
> 
> echo '(compile-file "$<" :output-file "$@") (quit)' | ${DEPSYS}
> 
> does not work with relative paths (it works fine with
> absolute paths).
> 

Waldek claims that the various Lisps do not implement a
uniform concept of "current directory", so therefore
relative paths behave differently in different Lisps
because it is not clear what is relative to what. This
does however work as expected (i.e. in the sense of
"current directory" implemented by both Linux and Windows)
when building Axiom from build-improvements using GCL on
both Linux and Windows.

In MSYS on Windows absolute paths do to work as you might
expect, but this has anything to do with Lisp. The problem
is that MSYS is a porting environment and so there are
really two *different* concepts of absolute path: one that
applies exclusively to the MSYS environment and associated
tools, and another one that applies in the native Windows
applications. During the Axiom build we need to use both
of these because we are building Axiom and its intermediate
phases as a native apps. If we choose to use absolute paths,
as is (mostly) done in wh-sandbox, then we must be careful
when we specify paths that must be interpreted by these
native windows programs.

Alternatively when compile Axiom on MSYS using GCL, as is
done in build-improvements, we can code things carefully so
that all paths are relative and this works because the
concept of current path is the same between MSYS and native
Windows.

> Related problem is handling '--output' parameter to
> 'document' script when compiling.
> 
> When I am writing about underlying problem I mean that
> we call 'compile-file' in Axiom and we want output in
> specific place (ATM what we get is "implementation
> dependent").
> 
> Note that compilation is part of user interface.  We
> can choose crippled interface (say only names in current
> directory), accept inconsincy between Lisps or we resolve
> this problem in general (for arbitrary paths).  I feel
> that we should resolve the problem.
> 

I do not think that resolving this problem for multiple
Lisp targets needs to be much of a priority for Axiom
right now. From my point of view it is enough that we
now have a version of the Axiom source that compiles
using GCL in ANSI mode. Being able also to compile
Axiom using other common lisps like SBCL and CLisp is
interesting but if their behaviour differs a little
because of implementation differences allowed by the
standard, I don't think that is such a big deal.

Perhaps you can convince me otherwise.

Regards,
Bill Page.