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

[Gabriel Dos Reis]

On Sun, 25 Feb 2007, Waldek Hebisch wrote:

| Gabriel Dos Reis wrote:
| > On Sat, 24 Feb 2007, Waldek Hebisch wrote:
| > | 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. ]
| >
|
| in the file gcl_cmpmain.lsp we have:
|
| (defun compiler-pass2 (c-pathname h-pathname system-p )
|   (declare (special *init-name*))
|   (with-open-file (st c-pathname :direction :output)
|     (let ((*compiler-output1* (if (eq system-p 'disassemble) *standard-output*
|                                 st)))
|       (declare (special *compiler-output1*))
|     (with-open-file (*compiler-output2* h-pathname :direction :output)
|       (cond ((and
|               (stringp *cmpinclude-string*)
|               (not system-p)
|               (si::fwrite *cmpinclude-string* 0
|                           (length *cmpinclude-string*) *compiler-output1*)))
|             (t (wt-nl1 "#include " *cmpinclude*)))
|
| So, if system-p argument to compiler-pass2 is true, it will try to
| use system include file.

Yes, I understood that part.

The link I'm missing is why Axiom's misbehaviour (reported by both
Gregory and Martin) is traced back to that.  Or am I lured by the
title of the thread? (I have been travelling the whole week, so I have
no access to all the discussion, only this one and some other bits).

| now in the same file in compile-file1 we have
|
|         (compiler-pass2 c-pathname h-pathname system-p ))
|
| and the beginning of compile-file1 is:
|
| (defun compile-file1 (input-pathname
|                       &key (output-file input-pathname)
|                            (o-file t)
|                            (c-file *default-c-file*)
|                            (h-file *default-h-file*)
|                            (data-file *default-data-file*)
|                            (c-debug nil)
|                            #+aosvs (ob-file nil)
|                            (system-p *default-system-p*)
|
| so during compile system-p is taken from *default-system-p*, unless
| a specific values is given as a keyword argument.

-- Gaby