Re: [Ecls-list] Building native EXE on Windows is too hard!

2012-11-15 Thread Juan Jose Garcia-Ripoll
On Wed, Nov 14, 2012 at 8:30 AM, Ralph Möritz wrote: > I don't think 64k is such a severe limitation; for code using very > long string literals couldn't we use embedded resources instead? > 64k is pretty small for many libraries out there that build tons of data. cl-unicode used to be one of tho

Re: [Ecls-list] Building native EXE on Windows is too hard!

2012-11-13 Thread Ralph Möritz
> Sorry, my name is Juanjo, not Franjo :-) Apologies, no disrespect intended. > Regarding compile-in-constants, I think you guys do not know the real > history. Microsoft's compiler has a severe limitation in compiler > string size. This means we cannot build constant data that takes more > than

Re: [Ecls-list] Building native EXE on Windows is too hard!

2012-11-09 Thread Juan Jose Garcia-Ripoll
On Thu, Nov 8, 2012 at 9:04 AM, Ralph Möritz wrote: > Re. #2, I don't really mind what ECL does with large constant strings > behind the > scenes, the point is that ECL *knows* which compiler it's using so it > *could* do whatever is necessary such as setting *COMPILE-IN-CONSTANTS* or > passing th

Re: [Ecls-list] Building native EXE on Windows is too hard!

2012-11-08 Thread Michael Wood
On 8 November 2012 11:45, Matthew Mondor wrote: [...] > For the library paths, on ELF systems RPATH can be used (such that the > runtime linker knows where to look for libraries without extra > configuration) and ECL is supposed to automatically link objects with > the required ECL library. Then

Re: [Ecls-list] Building native EXE on Windows is too hard!

2012-11-08 Thread Matthew Mondor
On Thu, 8 Nov 2012 04:45:22 -0500 Matthew Mondor wrote: > For the library paths, on ELF systems RPATH can be used (such that the > runtime linker knows where to look for libraries without extra > configuration) and ECL is supposed to automatically link objects with > the required ECL library. Th

Re: [Ecls-list] Building native EXE on Windows is too hard!

2012-11-08 Thread Matthew Mondor
On Thu, 8 Nov 2012 10:04:47 +0200 Ralph Möritz wrote: > Re. #2, I don't really mind what ECL does with large constant strings behind > the > scenes, the point is that ECL *knows* which compiler it's using so it *could* > do whatever is > necessary such as setting *COMPILE-IN-CONSTANTS* or passi

Re: [Ecls-list] Building native EXE on Windows is too hard!

2012-11-08 Thread Ralph Möritz
ne.net > To: ecls-list@lists.sourceforge.net > Subject: Re: [Ecls-list] Building native EXE on Windows is too hard! > > On Wed, 7 Nov 2012 15:16:57 +0200 > Ralph Möritz wrote: > > > 2. Why do we manually have to set C::*COMPILE-IN-CONSTANTS* to T? > > Some compilers h

Re: [Ecls-list] Building native EXE on Windows is too hard!

2012-11-07 Thread Matthew Mondor
On Wed, 7 Nov 2012 15:16:57 +0200 Ralph Möritz wrote: > 2. Why do we manually have to set C::*COMPILE-IN-CONSTANTS* to T? Some compilers have difficulty with large C constant strings, such that ECL had to append the data to the fasl files instead, but I thought that this problem was mainly a Vis

[Ecls-list] Building native EXE on Windows is too hard!

2012-11-07 Thread Ralph Möritz
Hi Franjo & all! back in July I started playing around with ECL with the goal of building a chess engine in Lisp. Back then I battled to get ECL to compile an EXE on Windows for a simple "hello world" program. You can read about my experience here: http://lispetc.posterous.com/chess-part-0-of-n