[FriBidi] Compilation for Windows environment

[Christophe GISQUET]

Hello,

my target is to build fribidi2 (from tarball of 0.19.1) by both mingw 
and Microsoft Visual Studio Express (ie free-as-in-beer). I think I've 
mostly succeeded. In the later environment, I'm using the 2005 edition, 
not caring about the latest versions.

I came across a number of difficulties:

1) Static vs dynamic library

Configure script, even after being rebuilt with my local versions of 
autotools (automake 1.9.5 and autoconf 2.59 which aren't the newest, I 
know), won't let me deactivate shared libraries (aka dll). At best, it 
builds both static and dynamic.

This is troublesome, because symbols from a shared library and a static 
library aren't named the same under Windows. This is somewhat handled by 
FRIBIDI_ENTRY define, except that it is forced to __declspec(import), 
which assumes dynamic:
http://msdn2.microsoft.com/en-us/library/8fskxacy(VS.80).aspx

Indeed, that's what configure tries to force. In that case, fribidi2 
isn't the only module behaving like this, and anyway, I guess it's up to 
me to assume my own choices (ease of packaging).

2) API partly deprecated

It seems fribidi_utf8_to_unicode and fribidi_unicode_to_utf8 are no 
longer directly available. Is it correct? I don't think so, because the 
symbol is really present in the library, so that would be a waste to not 
make it available.

3) struct tms
Is indeed unavailable under Windows. This is only a test program but yet 
you can find a patch attached to this mail so as to use the more 
classical clock function. I'll let you comment on the comments in this 
file instead of repeating them.

Anyway, I haven't tested the test programs, so I don't know if this is 
correct.

4) Support for Visual Studio compiler

I simply reused the generated config.h and fribidi-config.h from mingw, 
and edited them to match the VS environment. I then produced project and 
solution files (the equivalent of a Makefile) to only build a static 
library (no dynamic one, not test programs). This suits my needs, but to 
have it actually link with a program, the FRIBIDI_ENTRY define must be 
defined as empty.

About that last point, I'm not sure how much time I'd like to invest 
into having it work with the normal (shared lib) configuration.


The result is that the mingw version works (I could verify the correct 
glyphs are output for a string in farsi). I couldn't verify the visual 
version because the program I use for testing has a broken support for 
gettext, and I haven't yet been able to fix it...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fribidi-benchmark.diff
Type: text/x-patch
Size: 574 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/fribidi/attachments/20080408/dd196735/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fribidi-0.19.1.zip
Type: application/octet-stream
Size: 3002 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/fribidi/attachments/20080408/dd196735/attachment.obj