[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    mingw status
From:       syntheticpp () gmx ! net (=?ISO-8859-1?Q?Peter_K=FCmmel?=)
Date:       2006-03-04 17:24:28
Message-ID: 4409CD4C.6030504 () gmx ! net
[Download RAW message or body]

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.

> 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.

Peter
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kjs_binding_def.h
Url: http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060304/4e89b09f/attachment.h 

[prev in list] [next in list] [prev in thread] [next in thread]