[elephant-devel] Start of 0.6.1 Beta Cycle

[Ian Eslick]

I think the cygwin version is slow to update their versions and for  
various reasons we tend to depend on the latest release (4.5 in this  
case).

Your point on windows builds is well taken.  Here is a possible  
approach:

By default, we distribute DLLs with major releases and major  
development checkpoints.  There is a configuration option to inhibit  
compilation.  If people want to track the development tree, they'll  
have to enable this switch and then dig into why it doesn't work.   
The current DLLs shouldn't depend on cygwin (--no-cygwin --mingw32).   
However they'll only work on 32-bit Windows.

Does cygwin do cross-compilation for 64-bit windows?

Ian

On Mar 23, 2007, at 9:58 AM, Edi Weitz wrote:

> On Fri, 23 Mar 2007 09:19:49 -0400, Ian Eslick  
> <eslick at csail.mit.edu> wrote:
>
>> Any ideas for a better solution on your end?  I have to admit to an
>> extreme dislike of cygwin after a nasty summer in it's company some
>> years back.
>
> I think you can't really blame Cygwin in this case because Elephant
> uses the native BerkeleyDB Windows library although a Cygwin version
> is available:
>
>   http://www.oracle.com/technology/documentation/berkeley-db/db/ref/ 
> build_win/intro.html
>
> It'd probably be better to change the build process and use that one,
> but I haven't tried.  The downside might be that you can't use the
> resulting DLL in a non-Cygwin environment anymore.
>
> My preferred solution would be to distribute Cygwin-independent
> pre-compiled DLLs (maybe generated with Visual Studio) for memutil and
> db-bdb like CLSQL does it.  Experience shows that "automatic" command
> line builds of C programs on Windows almost never work and Windows
> users are neither prepared nor willing do dig into this stuff.
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel