<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Thank you for forwarding, and I found my answer in the source code,<br></div><div class="gmail_default" style="font-family:monospace,monospace">namely in cpmain.lisp, around line 471.  It tells you to set the optino<br></div><div class="gmail_default" style="font-family:monospace,monospace">:c-file "foo.c", for example, when calling compile-file.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">thanks again<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 25, 2015 at 10:16 PM, Daniel Kochmański <span dir="ltr"><<a href="mailto:daniel@turtleware.eu" target="_blank">daniel@turtleware.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm not sure if I miss something, but this mail seems to be sent to the<br>
<a href="mailto:ecl-devel-owner@common-lisp.net">ecl-devel-owner@common-lisp.net</a> . Correct ML address is<br>
<a href="mailto:ecl-devel@common-lisp.net">ecl-devel@common-lisp.net</a> . I'm fast forwarding the mail there.<br>
<span class=""><br>
Brian Beckman writes:<br>
<br>
> Hello --<br>
><br>
> I am experimenting with ECL for actual embedded applications<br>
> (in the sense of "embedded systems," i.e., small computers running<br>
> disconnected controller software.<br>
><br>
> The hardware team insists on inspecting the generated C code from<br>
> the ECL compiler.  I found, in the ECL manual, directions for<br>
> producing .o files, .a files, .fasl files, and standalone executables.<br>
> I also found prose that says that it is possible to emit the<br>
> actual .c and .h files.  However, I can't find instructions on how<br>
> to emit the actual .c and .h files.<br>
<br>
</span>Generated code is readable, but it's a generated code after all. It's<br>
not pretty.<br>
<span class="">><br>
> I can (compile-file "hello.lisp" :system-p t), but that produces<br>
> only a .o file.  I need to see the .c and .h files.  My hardware<br>
> team won't permit ECL-generated code until they can visually read<br>
> and inspect the generated .c and .h files.<br>
<br>
</span>To prevent ECL from deleting these intermediate files you need to set<br>
special variable c::*delete-files* to nil.<br>
<br>
  (setf c::*delete-files* nil)<br>
<br>
Intermediate files are *.c, *.h and *.data . The last one contains some<br>
untranslatable expressions (rare occasion – if you work with infinities<br>
for instance) and debugging/reflection information (like the path to the<br>
source file).<br>
<br>
This problem has been tacled by Earl Ducaine here:<br>
<a href="https://github.com/earl-ducaine/stupid-ecl-tricks-1" rel="noreferrer" target="_blank">https://github.com/earl-ducaine/stupid-ecl-tricks-1</a> .<br>
<span class="">><br>
> Can you help me figure out how to generate them?  I can't find<br>
> the instructions in the manual.  I am starting to read the source<br>
> code, but perhaps you can give me correct pointers into the manual<br>
> or some other kind of instructions.<br>
<br>
</span>I'm now in-process of revising manual and rewriting it into texi<br>
sources. I'll keep in mind to document this. It would be great<br>
if you could file an issue on<br>
<a href="http://gitlab.com/embeddable-common-lisp/ecl/issues" rel="noreferrer" target="_blank">gitlab.com/embeddable-common-lisp/ecl/issues</a> (with the label<br>
"documentation"). Thanks!<br>
<br>
><br>
> Thanks!<br>
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Daniel Kochmański | Poznań, Poland<br>
;; aka jackdaniel<br>
<br>
"Be the change that you wish to see in the world." - Mahatma Gandhi<br>
</font></span></blockquote></div><br></div>