KDE Thai Word Break patch

[Otto Pattara]

Hello,

It was "lib = loader->library("libthai.so.0")" because at that time it 
was found that specifying only "libthai" will require existence of 
"libthai.la", i.e. it doesn't try further to libthai.so*. Not sure if 
this is the desired behavior though. IMHO it should try a bit 
further. Anyway, let's go for loader->library("libthai") then. 

As some platforms don't support dlopen. How about supporting both 
compile-in and dlopen? 

(1) configure --with-libthai=yes ---> will link against libthai at the 
compile time.

(2) if it is compiled WITHOUT (1) --->  the code tries to load 
"libthai" dynamically using KLibLoader facility.

Attached please find my new patch reflecting this. If HAVE_LIBTHAI is 
defined, it goes with (1).

Then we would need to add something like below (?). Please advise...

kdelibs/khtml/configure.in.in:
[...]
+KDE_CHECK_LIBTHAI

admin/acinclude.m4.in:
[...]
+ AC_DEFUN([KDE_CHECK_LIBTHAI],
+ [
+ AC_MSG_CHECKING([if libthai should be compiled in])
+ AC_ARG_WITH(libthai,
+    AC_HELP_STRING(
+      [--with-libthai=yes],
+      [add Thai-language support from libthai library [default=no]]
+    ),
+   [ ac_libthai=$withval],
+   [ ac_libthai=no ]
+ )
+    if test "$ac_libthai" != "no"
+        AC_DEFINE(HAVE_LIBTHAI, "$ac_libthai",
+  [Defined if you have libthai and want to have it compiled in])
+        LDFLAGS="$LDFLAGS -lthai"
+    fi
+    AC_MSG_RESULT($ac_libthai)
+ ])

Cheers,
Pattara

On Saturday 13 November 2004 20:54, Germain Garand wrote:
> Le Samedi 13 Novembre 2004 08:48, Otto Pattara a écrit :
> > In this case I'm afraid I would ask to ask you for sending some
> > autotool wizards to rescue me? :)
>
> I don't have one at hand, but as a mere mortal, I'd simply suggest:
>
> admin/acinclude.m4.in:
> [...]
> + AC_DEFUN([KDE_CHECK_LIBTHAI_DLOPEN],
> + [
> + AC_MSG_CHECKING([for libthai shared object name or full path])
> + AC_ARG_WITH(libthai,
> +    AC_HELP_STRING(
> +      [--with-libthai=name_or_path],
> +      [try to dlopen libthai using name_or_path at runtime,
> besides looking for a libtool file]
> +    ),
> +   [ ac_libthai=$withval],
> +   [ ac_libthai=default ]
> + )
> +    if test "$ac_libthai" != "default"
> +        AC_DEFINE(HAVE_LIBTHAI_DLOPEN, "$ac_libthai",
> +  [Defined if a name or full path to libthai was provided at
> configure time for dlopen use])
> +    fi
> +    AC_MSG_RESULT($ac_libthai)
> + ])
>
> kdelibs/khtml/configure.in.in:
> [...]
> +KDE_CHECK_LIBTHAI_DLOPEN
>
> in your patch, khtml/rendering/break_lines.cpp:
> [...]
> +#include <config.h>
> [...]
> +            KLibLoader *loader = KLibLoader::self();
> +#ifdef  HAVE_LIBTHAI_DLOPEN
> +              lib = loader->library(HAVE_LIBTHAI_DLOPEN);
> +              if (!lib || !lib->hasSymbol("th_brk"))
> +#endif
> +            lib = loader->library("libthai");
> +            if (lib && lib->hasSymbol("th_brk")) {
> +                th_brk = (th_brk_def) lib->symbol("th_brk");
> [...]
>
> isn't that enough?
>
> Germain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml-3.3.1-thai-20041114.diff
Type: text/x-diff
Size: 5799 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20041114/6c3177de/attachment.diff>