axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Bug with paths in wh-sandbox


From: Waldek Hebisch
Subject: Re: [Axiom-developer] Bug with paths in wh-sandbox
Date: Sat, 24 Feb 2007 04:16:09 +0100 (CET)

Gabriel Dos Reis wrote:
> Martin Rubey <address@hidden> writes:
> 
> | I made wh-sandbox available on my linux box for other members of the
> | departement by setting the file permissions of
> | 
> | ~/axiom
> | 
> | (the install directory) appropriately. However, it seems that axiom wants 
> the
> | build directory to be availble. I received the following notice:
> 
> The current handling of paths in Axiom (Gold) and its branches 
> are just dead plain wrong.  some of the issues were corrected in
> build-improvements (therefore wh-sandbox), but most of them remain.
> I consider that your report and that of Gregory are related and fall
> in the same basket.
> 

After some investigation it turend out that eariler versions do not
need "cmpinclude.h" -- gcl simply puts inline content of this file.
gcl behaviour is controlled by the Lisp compiler::*default-system-p*
variable, which is set to t.  As a workaround one can use the following
in the start script:

)lisp (setf compiler::*default-system-p* nil)

AFAICS the problem was interoduced in version 25 (patch 45): this
variable is set to t when using system installed gcl.  Typically
this is not a problem, but I belive that if somebody builds gold
using system installed gcl (assuming that this would work ...)
and then puts the content of Axiom directory on a machine whithout
installed gcl, then the same problem would appear.

Now, the question is how to solve the problem.  One way is to patch
src/lsp/Makefile.pamphlet so that it does not set 
compiler::*default-system-p* to t.  Another possibility is to
set compiler::*default-system-p* to nil when dumping final AXIOMsys.
For me the second possibility looks slightly better, as it avoids
putting extra crud into intermediate C files.

>From my point of view nicest solution would be to teach gcl check
if cmpinclude.h is in expected place, if yes use it, otherwise
use cached version.

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]