Peter Kümmel schrieb: > Ralf Habacker wrote: > >> Peter Kümmel schrieb: >> >>> Ralf Habacker wrote: >>> >>> >>>> Can you send a patch for the second solution that I can give it a try ? >>>> Ralf >>>> >>>> >>>> >>> Attached the patch, it's not perfect - especially the macro naming. >>> Peter >>> >>> >> There is an alternative approach in test-kjs.patch. >> >> The appended testcase shows that mingw is able to deal with this stuff >> in an easy way. The only thing to do is to prepend a KDE_USTRING_EXPORT >> define to methods, which are not implemented in kjs. May be this name >> isn't a god choice and could be easly changed. >> >> Please unpack the test.zip archive into kdelibs, make sure, kjs lib is >> build and run make in the test dir. Then you have a local libhtmk.dll, >> which implements Ustring methods and an exe which uses kjs and local lib >> provided UString methods. >> >> Any comments ? >> >> Ralf >> >> > > It's the only(?) simple alternative we have > to the inline solution. > > But then we must move all the relevant > kjs_binding.cpp code into a extra file which > will build into the additional shared library. > Why ? If you define KDE_USTRING_EXPORT for the methods located in libkhtml when compiling to dllexport, than any functon in libkhtml which requires any of this function will look for a symbol in the recent library not for an external in the kjs library. This is what the test-kjs.patch does, or does I have misunderstand something important ?
The *.ii files in the testcase shows how the export definition of single UString members looks. > Isn't it simpler just to inline for all compilers? > It also gives us a little speed-up. > I don't know about the reasons, why they are defined in kjs_binding.cpp About how many functions are we talking ? Ralf _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
