Subject: [clisp-list] (compile-file "foo.lisp") deletes foo.c ??

From: [email-masked] (Don Cohen)
Date: Sat Mar 15 17:38:19 2003

Any idea why this is?
I know it's hard to believe, but I did strace of clisp doing
compile-file and I see 
 ...
 readlink("/root" ... 
(I'm doing this from root - does that matter?)
 lstat64("/root/foo.c" ...
 readlink("/root" ... 
 lstat64("/root/foo.c" ...
 unlink("/root/foo.c")
 ...

---

From: Sam Steingold <[email-masked]>
Date: Sun Mar 16 10:20:01 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] (compile-file "foo.lisp") deletes foo.c ??"
> * Sent on Sat, 15 Mar 2003 17:33:36 -0800
> * Honorable [email-masked] (Don Cohen) writes:
>
> Any idea why this is?

<http://clisp.cons.org/impnotes.html#compilefile>:
<http://clisp.cons.org/impnotes/system.html#compilefile>:

Warning   If you have two files in the same directory - #P"foo.lisp"
          and #P"foo.c", and you compile the first file with CLISP,
          the second file will be clobbered if you have any "FFI" forms
          in the first one!

(this is relevant only for the latest CLISP, older versions clobbered
the C file even if you had no FFI forms).

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
My other CAR is a CDR.

---

From: [email-masked] (Don Cohen)
Date: Sun Mar 16 11:26:14 2003

> the C file even if you had no FFI forms).

hmm, not in my (out of date) impnotes, of course.

The reference above doesn't tell me why this is necessary or
reasonable.  It seems to me clearly undesirable.
It also says "only if :OUTPUT-FILE is not NIL".  What does that
have to do with it?  It doesn't mention what the value of NIL means.
Also that table says "default" file type.
That suggests there's a way to override it.  How?

The FFI forms suggests that this file is being written to support
FFI forms.  Is it then to be compiled?  If so, there must be another
output file (which seems to be undocumented) - I didn't lose my foo.o
file.  

Tell me where I can find out the details of what's going on so that
I can try to find some better alternative.

---

From: Sam Steingold <[email-masked]>
Date: Sun Mar 16 15:17:26 2003

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] (compile-file "foo.lisp") deletes foo.c ??"
> * Sent on Sun, 16 Mar 2003 11:21:49 -0800

maybe it's time to upgrade?

> have to do with it?  It doesn't mention what the value of NIL means.

:OUTPUT-FILE NIL means do not write *.fas.
CLHS should explain that.

> That suggests there's a way to override it.  How?

:OUTPUT-FILE "foo.baz" will write "foo.baz" instead of "foo.fas".
you cannot change the LIB, C and LIS file types.

> The FFI forms suggests that this file is being written to support FFI
> forms.  Is it then to be compiled?  If so, there must be another

you have to invoke a C compiler on the generated C file yourself.

> I can try to find some better alternative.

Look at the bindings/linuxlibc6 module (and the modules docs in
general).
CLISP sources have src/foreign.d and src/foreign1.lisp, src/dirkey.d
and src/dirkey1.lisp - for this exact reason.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
The software said it requires Windows 3.1 or better, so I installed Linux.

---

From: [email-masked] (Don Cohen)
Date: Sun Mar 16 16:32:05 2003

> CLHS should explain that.
nope

 > you cannot change the LIB, C and LIS file types.

I never understood the lib file either, now that you mention it.

 > you have to invoke a C compiler on the generated C file yourself.

ok, I see under Extensions-2.3. The Foreign Function Call Facility:
 A foreign function description is written as a Lisp file, and when
 compiled it produces a .c file which is then compiled by the
 C compiler and may be linked together with lisp.a.

Is there any reason that file has to be foo.c ?
Could there be an argument to compile-file to specify where this
and any other generated files go?
Could the default be something less likely to be already used,
say foo-ffi.c ?
Could the default behavior even be that such generated files
start with some sort of identifying comment, such as
 /* generated from foo.lisp by clisp compiler (version ...) */
and that if the file already exists and does not have that 
comment, an error is generated?

The fact that recent versions (more recent than mine) don't clobber 
foo.c when foo.lisp has NO FFI stuff in it is certainly a step in
the right direction and suggests that someone is aware of the
problem and is willing to do something to fix it.  Let me know if
you think my help in implementing any of the suggestions above will
be of any value.

 > Look at the bindings/linuxlibc6 module (and the modules docs in

I found this, but don't see quite what you think I should look for.
In any case, I think the above quotation from impnotes supplies
enough information for now.

 > and src/dirkey1.lisp - for this exact reason.

I see, I'm not the first to be bitten by this, but the "solution" that
was chosen won't prevent people like me from being bitten in the future.

---

From: Sam Steingold <[email-masked]>
Date: Sun Mar 16 20:14:23 2003

> * In message <[email-masked]>
> * Sent on Sun, 16 Mar 2003 16:27:03 -0800

Did it occur to you to _click_ on the underlined "lib" in the impnotes?!
<http://clisp.cons.org/impnotes/system.html#require>

> and any other generated files go?

can you tell 'gcc -c foo.c' to write object file in foo.obj and not
foo.o?

> Could the default be something less likely to be already used,

There is a general idea that if you have a set of files named foo.*,
then one of them, say, foo.lisp, is the master, and the rest, e.g.,
foo.fas, foo.lib, foo.lis, foo.txt, foo.c are generated from it.
Not everyone subscribes to it, of course.

> comment, an error is generated?

sounds reasonable.
even if this is implemented, you will need to upgrade to benefit from
this, though...
It is not clear that this will bring much benefit compared with the
current behavior (as opposed to what you observe).
What do other users think?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
I'm a Lisp variable -- bind me!

---

From: [email-masked] (Don Cohen)
Date: Sun Mar 16 20:50:19 2003

> <http://clisp.cons.org/impnotes/system.html#require>

Another thing that's been added to impnotes since my old version...
Interesting.  Not standard for common lisp, unless the standard has
changed recently.

 > can you tell 'gcc -c foo.c' to write object file in foo.obj and not

gcc -o foo.obj -c foo.c

But what's that have to do with it?  We're not trying to make lisp
conform to c limitations are we?  You can, for instance, supply and
output-file argument to compile-file.  If it were expected that
compile file would generate multiple files I'm sure there would have
been arguments in the spec to control those too.

 > Not everyone subscribes to it, of course.

Actually my mistake was programming in c.  But I have no choice when
I want to write a module to be loaded into the linux kernel.
Then I need to write a program to use the module and, of course,
I want to write that in lisp.  It seems natural to name them the
same other than the .c/.lisp, or at least it did before I compiled
the lisp.

 > even if this is implemented, you will need to upgrade to benefit from
Yes, I recognize this.
You always want me to upgrade.  I'm just trying to give myself more
incentive.