Hey,
I'm glad that it worked for you. Regarding compiling to a file, you may specify
c-file, h-file and data-file
as keyword arguments to compile-file, if definitions are kept then these files
won't be removed.
Best regards,
Daniel
--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu
"Be the change that you wish to see in the world." - Mahatma Gandhi
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 28 November 2020 19:18, Garrett Dangerfield
<garr...@dangerimp.com> wrote:
> First off, I very much appreciate your patience and help as I got this going.
> But I HAVE got it going.
>
> I used the MS Visual Studio nmake to get it working and it's the 32-bit not
> the 64-bit. I may poke at trying 64-bit along the way but it's lower priority.
>
> I do have to run "(ext:install-c-compiler)" each time I start the ECL REPL,
> just FYI.
>
> The biggest issue I faced was that my Lisp code wouldn't compile. First it
> complained about missing .h files and then it complained about missing .lib
> files. Basically, it needed system level additional pathing for both the .h
> files and the .lib files passed to "cl".
>
> This may or may not be the best solution, but what I did was change
> cmpmain.lsp to include two new variables (c::*ecl-include-directory-extra*
> and c::*ecl-library-directory-extra*). They are both lists and they are
> "extra" directories needed during the compile and linking phases.
>
> The values I had to set mine to were:
> (setf c::*ecl-include-directory-extra*
> '("c:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/ucrt/"
> "c:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include/"
> "c:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/um/"
> "c:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/shared/"
> ))
> (setf c::*ecl-library-directory-extra*
> '("c:/Program Files (x86)/Windows Kits/10/Lib/10.0.18362.0/um/x86/"
> "c:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/lib/"
> "c:/Program Files (x86)/Windows Kits/10/Lib/10.0.18362.0/ucrt/x86/"
> ))
>
> I've attached my modified cmpmain.lsp. Please feel free to use/not use, etc.
> however you desire (legal release granted blah blah blah).
>
> A minor issue I'm currently facing is that I'd like to look at the C code
> generated but when I set "(setq si::*keep-definitions* t)" it doesn't seem to
> have any effect. If there's another way to keep the C code, please let me
> know.
>
> Also, the exe that's generated only seems to want to work right if the
> ecl.dll is in the same directory, but that's fairly minor right now.
>
> The next goal I have is to try and connect my Lisp up to C/C++ code and
> generate an actual working Windows GUI program (meaning actually create a
> window but having the drawing portion of the window and the Windows messaging
> be handled by Lisp code, ideally allowing real-time modification of the LIsp
> while the window still up and running). I'll send updates as appropriate. I
> may create a blog post somewhere with my ongoing adventures.
>
> Thanks again for your help,
> Garrett Dangerfield.
>
> On Thu, Nov 26, 2020 at 1:13 PM Daniel Kochmański <dan...@turtleware.eu>
> wrote:
>
>> Garrett: please put ecl-devel as the address (that may be my fault that I've
>> hit reply earlier).
>>
>> Re your problem, please ensure, that c compiler is in the path.
>>
>> -------- Oryginalna wiadomość --------
>> 26 lis 2020, 20:45, Garrett Dangerfield napisał(a):
>> I got a compile to work with Visual Studio. I set:
>> ECL_CMP = 1
>> and it's at least trying to generate a .o file instead of an .fasc file. I'm
>> running this:
>>> (ext:install-c-compiler)
>>
>> ;;; Loading #P"C:/Users/danger/Downloads/ecl-20.4.24/msvc/cmp.fas"
>> NIL
>>> (compile-file "t2.lsp" :system-p t)
>>
>> ;;;
>> ;;; Compiling t2.lsp.
>> ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
>> ;;;
>> ;;; End of Pass 1.The system cannot find the file specified.
>>
>> ;;; Internal error:
>> ;;; ** Could not spawn subprocess to run "cl".
>> NIL
>> T
>> T
>>> And its' creating these files:
>> -rwxr-xr-x+ 1 danger None 1930 Nov 26 11:40 t2.c
>> -rwxr-xr-x+ 1 danger None 395 Nov 26 11:40 t2.data
>> -rwxr-xr-x+ 1 danger None 599 Nov 26 11:40 t2.eclh
>>
>> Thoughts? Were there other settings I needed to tweak during the ECL compile?
>>
>> Thanks,
>> Garrett.
>>
>> On Thu, Nov 26, 2020 at 9:54 AM Garrett Dangerfield <garr...@dangerimp.com>
>> wrote:
>> Thanks, I found the section of the manual right after I clicked send, of
>> course.
>>
>> Thanks.
>>
>> On Thu, Nov 26, 2020 at 9:50 AM Daniel Kochmański <dan...@turtleware.eu>
>> wrote:
>> You don't call configure on msvc build, check out install file and the manual
>>
>> Wysłano z aplikacji ProtonMail
>>
>> -------- Oryginalna wiadomość --------
>> 26 lis 2020, 17:58, Garrett Dangerfield napisał(a):
>>
>> So if I use Visual Studio, will I still use cygwin to do the ./configure?
>>
>> On Thu, Nov 26, 2020 at 8:55 AM Daniel Kochmański <dan...@turtleware.eu>
>> wrote:
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Thursday, 26 November 2020 17:51, Garrett Dangerfield
>> <garr...@dangerimp.com> wrote:
>>
>> I tried your suggestions and I tried the cygwin patch as well, no luck,
>> that's why I tried to pull cygwin out of the equation. Neither seem to be
>> producing an EXE that could understand an external compiler.
>>
>> With the non-cygwin configuration, I'm baffled on why configure says things
>> are kosher but the compile fails for missing file, though.
>>
>> Thoughts?
>>
>> No, sorry. All I can think of is using msvc. Generally ECL expects that he C
>> compiler used will be the same compiler
>> ECL was built with itself.
>>
>> Thanks,
>> Garrett.
>>
>> On Thu, Nov 26, 2020 at 3:05 AM Daniel Kochmański <dan...@turtleware.eu>
>> wrote:
>> ECL may be build with cygwin/mingw, then it works with cygwin/mingw runtime.
>> You may also use
>> MSVC, then you need to enter the msvc directory and issue nmake (see
>> documentation for more
>> precise instructions).
>>
>> That said, did you try my previous suggestion with passing appropriate flags
>> to cygwin?
>>
>> Regards,
>> Daniel
>>
>> --
>> Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
>> TurtleWare - Daniel Kochmański | www.turtleware.eu
>>
>> "Be the change that you wish to see in the world." - Mahatma Gandhi
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Wednesday, 25 November 2020 23:11, Garrett Dangerfield
>> <garr...@dangerimp.com> wrote:
>>
>> So I zapped the gcc/g++, etc. from cygwin and did an install of mingw 64 bit
>> outside of cygwin. I added the big directory from that to my path.
>>
>> I did the "./configure --with-cmp=yes" and it finished:
>> config.status: creating ecl/config.h
>> config.status: creating ecl/config-internal.h
>> Configuration complete. To build ECL, issue make in this directory.
>>
>> But make is failing:
>> $ make
>> cd build; make
>> make[1]: Entering directory
>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build'
>> c doc gc atomic
>> make[2]: Entering directory
>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic'
>> Making all in src
>> make[3]: Entering directory
>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>> make all-am
>> make[4]: Entering directory
>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>> /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I../src
>> -I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src
>> -Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT
>> atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c -o atomic_ops.lo
>> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
>> libtool: compile: gcc -DHAVE_CONFIG_H -I../src
>> -I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src
>> -Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT
>> atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c
>> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
>> -o atomic_ops.o
>> gcc.exe: error:
>> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c:
>> No such file or directory
>> gcc.exe: fatal error: no input files
>> compilation terminated.
>> make[4]: *** [Makefile:610: atomic_ops.lo] Error 1
>> make[4]: Leaving directory
>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>> make[3]: *** [Makefile:473: all] Error 2
>> make[3]: Leaving directory
>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>> make[2]: *** [Makefile:475: all-recursive] Error 1
>> make[2]: Leaving directory
>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic'
>> make[1]: *** [Makefile:129: libeclatomic.a] Error 2
>> make[1]: Leaving directory
>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build'
>> make: *** [Makefile:65: all] Error 2
>>
>> Obviously, on windows I still have to use cygwin as my shell because that's
>> what configure expects.
>>
>> Thoughts?
>>
>> Thanks,
>> Garrett.
>>
>> On Wed, Nov 25, 2020 at 10:03 AM Daniel Kochmański <dan...@turtleware.eu>
>> wrote:
>> So the problem seems to be quite clear: your ecl build doesn't have the C
>> compiler enabled.
>> When you configure the build, include --with-cmp=yes (or builtin).
>>
>> ./configure --prefix=/my/cygwin/prefix --with-cmp=yes
>> make && make install
>>
>> Then C compiler should be available (you may still need to call
>> (ext:install-c-compiler), you need
>> to check it yourself because I don't remember whether bytecodes compiler is
>> installed by default
>> on cygwin, it is for msvc).
>>
>> If it still doesn't work, please include a result of calling this code
>> snippet:
>>
>> (format t "~&~@{~12@A ~S~%~}"
>> :version (lisp-implementation-version)
>> :vcs-id (ext:lisp-implementation-vcs-id)
>> :os (software-type)
>> :os-version (software-version)
>> :machine-type (machine-type)
>> :features *features*)
