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: Gabriel Dos Reis
Subject: Re: [Axiom-developer] Bug with paths in wh-sandbox
Date: Sat, 24 Feb 2007 20:54:45 -0600 (CST)

On Sat, 24 Feb 2007, Waldek Hebisch wrote:

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

You have spent some time investigating this; but, unfortunately I do
not see the direct link to GCL stuff being system-wide or not.
Please could you walk me (slowly) through your invesgitation?

[ I just saw your patch, but I would first like to see why the
  patch is correct at the "algorithmic" level. ]

Thanks,

-- Gaby




reply via email to

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