Dimitrie O. Paun wrote:
On August 15, 2002 12:08 pm, Shachar Shemesh wrote:
configure.ac: 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 runtime.
Con:
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 tested.
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 marginally).
Shachar