Handling Soprano and Qt4.5 source-incompatibility

[Sebastian Trüg]

On Thursday 25 September 2008 15:26:11 Olivier Goffart wrote:
> 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

easiest thing: www.sf.net/soprano. Mailing lists as usual.

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

The symbol is not exported anyway. So in the end, just removing it should not 
be a problem.

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

We cannot break BC in Soprano. It is exposed in kdelibs. Sadly I did not think 
of such issues at the release of kde 4.0.

> 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 :-)

Cheers,
Sebastian