mingw status

[Ralf Habacker]

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