Handling Soprano and Qt4.5 source-incompatibility

[Olivier Goffart]

Le jeudi 25 septembre 2008, Andreas Pakulat a écrit :
> Hi,
>
> I can't find a dedicated list for soprano, hence I'm raising the issue
> here. Yesterday I comitted a change that was proposed here to restore
> binary compatibility in Soprano after a change needed for compilation
> with Qt4.5.
>
> Short story: Qt4.5 breaks source compatibility by moving the QHash
> #include a bit further up in the chain of includes (into QVariant). This
> causes problems when you're defining your own global qHash function for
> a class that lives in a namespace. The fix is to move the qHash function
> into the same namespace as the class for which its being used.
>
> The move is binary incompatible, so in theory leaving the old global
> qHash and just adding another thats inside the namespace should solve
> this. Unfortunately this doesn't work. When both functions exists gcc
> cannot decide which one to use, the qHash call is ambiguous and there's
> no way to help it resolve that.

Remove the old one from the header, only keep it in the .cpp file.
That way, symbol will be generated for compatibility. And other sources unit 
will only see the new one. 


> Mostly I'm writing this to check wether I should restore BC and
> compilability (which then breaks compilation with Qt4.5 for now) or do
> the BiC change and Sebastian will release a new version of soprano
> before Qt4.5 hits the streets?

I think one way to restore source compatibility would be to move all the qHash 
functions from the begining of qhash.h to the end of the same file.  
Althought I'm not 100% sure it would be 100% correct :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080925/51cb4242/attachment.sig>