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
<[EMAIL PROTECTED]> 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@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
