mingw status

Ralf Habacker ralf.habacker at freenet.de
Sat Mar 4 21:32:33 CET 2006


Ralf Habacker schrieb:
> 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.
Update: Saw just an build issue with the previous patch, global.h.cmake 
was not updated. The appended includes this fix.

Ralf
>>> 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
>   

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


More information about the Kde-buildsystem mailing list