Add BiDi infrastructure
wine-devel at sun.consumer.org.il
Fri Aug 16 11:43:18 CDT 2002
Dimitrie O. Paun wrote:
>On August 15, 2002 12:08 pm, Shachar Shemesh wrote:
>> Added a check for the existance of the fribidi include file. No
>>check for the library, as we do not statically link with it.
>Like any programmer, I usually hate copying stuff around, but in this
>case isn't it better to simply have a copy of the fribidi heades around?
>I mean, we do the runtime load and checks anyway, why do we need
>to have the header around? If we don't use much out of the header,
>I would say simply include the prototype of the functions we're calling
>into the dlls/gdi/fribidi.c file directly, and be done with it. No configure,
>no macros, no ifdefs, no mess.
NOW you remeber to tell me about this? ;-)
But seriously, if I've already took the time to learn that tiny bit of
autoconf necessary to implement this, and we already have the define, I
think it is best to just leave it there. The argument, as I can see it,
goes like this:
Pro adding it:
1. Allows you to compile with or without, saving on runtime checks
(not really an issue - MS does, as of Windows 2000, basically the
same thing with a DLL called "LPK.DLL", Language Pack).
2. libfribidi is LGPL. If wine depends on it included to compile, we
can't negotiate BiDi with rewine's code users for some other
feature (unless the aprox. four libfribidi copyright owners give
their consent, of course).
3. Remain in sync with the library with which we intend to link in
1. Need to write code (not an issue - code is already written).
2. No chance of packagers forgetting this library (not an issue - if
packagers want this package removed, it's their own choice. That's
what open source is all about).
3. A way to eliminate BiDi bugs (I don't think it's an issue - bugs
need to be resolved anywhere they exist).
4. The library dependancy is expected to change if Behdad stands by
his word of supplying a UTF-16 libfribidi (but then we will want
the new library in the same way, won't we?)
5. Creating two variants of the code that, in theory, both need to be
Of all these issues, I see Pro(3) and Con(5) as bearing any real
relevance. In particular, Con(5) is the exact thing that made Windows
2000 with Hebrew so much better than any other MS Hebrew speaking OS. As
I noted before, however, W2K really uses the runtime link methodology.
If the general public here votes to remove the ac related code, I'll go
along with it (no question about it making my code simpler, albeit
More information about the wine-devel