[TRE-general] cygwin problem

[skaller]

On Wed, 2006-05-10 at 20:01 +0300, Ville Laurikari wrote:

>  It detects the target system type (by default it's the
> same as the host, but cross compilation is also supported) 

Can I just say

CC=gcc -mnocygwin ./configure

Or on linux

CC=/usr/something/i686-mingw/bin/gcc ./configure

and expect a windows DLL to be generated??

> There is no need for a --mingw option.  

So what option do I use? There has to be a way to
identify the target environment.

> I just built tre-0.7.3 on mingw.  It suffers from the same problem as
> Cywin, and you need to use --enable-static.  This will be fixed in
> 0.7.4.  

BTW: I'm using the darcs head on Linux. I'm not sure exactly
how to do the familiar CVS like operations, eg update,
generate a patch, etc, or package it up so I can move the
sources to my other boxes for testing.

> Additionally, there is some problem with wide/multibyte
> characters, and you also need to use --disable-wchar to turn it off.
> With those two configuration flags tre-0.7.3 builds and the regression
> test suite passes on mingw.

Curious how you're running the regression tests.
You cannot run tests when cross compiling, without switching
to the target machine.

> The wide char problem is strange.  It works fine with Cygwin and
> native Windows, and I don't really know what the difference could be.

On linux (at least amd64), wchar_t is 32 bits, on Windows it is 16 bits.
Cygwin seems to use 16 bits so this doesn't really explain it.

I have some questions on whether some more 'inner' parts of
TRE can be exposed to provide a saner API. For example, 
a combinator form for regexps instead of a string, ways to
represent large sets of chars (eg all unicode identifiers).
String regexps are evil but they're convenient for 
micky mouse applications.

Also if the wchar_t support can be augmented with 32 bit
integer support (since int32_t is the correct type for
unicode UCS-4 representation).

> In addition, the mingw debugger sucks pretty bad (for example, you
> cannot get a backtrace from system functions to application code) and
> makes debugging it so annoying I stopped after a while.

But visual Studio has a superb debugger :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net