mingw status

Ralf Habacker ralf.habacker at freenet.de
Sat Mar 4 20:54:00 CET 2006


Peter Kümmel schrieb:
> Ralf Habacker wrote:
>   
>>> 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 ?
>>
>>     
>
> Next time when I compile with mingw I'll give it a try.
> And you are right, I also don't see a reason why it should not work.
>
> But this solution introduces a additional shared library and
> this is the reason I don't like very much.
>   
No, the testcase simulates the usage of kjs, khtml and other client 
libraries/applications, which covers all available cases I know, which are:

1. compile kjs -> declare a method, but do not define it.
2. compiling khtml ->
    a. define methods declared by kjs
    b. use methods declared by kjs and defined in khtml
3. compile other libraries, which uses methods from kjs as well from khtml

The appended patch fixes this issue for whole kjs.


>> 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 
>>     
>
> As I understand it, the reasons for these functions are to help the kde
> development but also avoids the binding to Qt when compiled at Apple.
>
>   
>> About how many functions are we talking ?
>>
>>     
>
> See the attached file which contains all the inline code and which
> I forgot to post with the last patch.
>   
No problem, this patch isn't required anymore, only the appended 
kjs-external.patch.  Linking khtml does not have any kjs related 
problems anmore, only png related symbol missing error. Seems that png 
isn't detect on my checkout.

If you see no problem, I will check this in.


Ralf

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kjs-external.patch
Url: http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060304/3ba40a44/attachment.ksh 


More information about the Kde-buildsystem mailing list