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: Sun, 25 Feb 2007 04:41:54 +0100 (CET)

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.

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.

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

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