fix build with qt6

[jmlich]

No description provided.

[Tofee]

@jmlich I see a reference to the -qt5 suffix still here: https://github.com/jmlich/sensorfw/blob/master/core/loader.cpp#L58 , is that a mistake?

[jmlich]

Thanks for spotting of the issue and patch. I must admit that I haven't done much tests.

[mlehtima]

Could you squash the commits into one and use commit message that matches the existing commits so something like "[sensorfw] Fix build with Qt6". Also make sure your fork has all tags from this repo so it's easier for me to test the builds without forking your branch.

[jmlich]

I am not sure if you know, that it is possible to squash commits during merge

[jmlich]

I have also changed mkspec path same as in sailfishos/libiodata#5

[Thaodan]

See comments.

I wonder if we can't just define Qt::SkipEmptyParts before Qt 5.14.

[Herrie82]

Qt::SkipEmptyParts

I came across something like this: goldendict/goldendict@c4dcd4d

I'm sure there are other solutions too

[Thaodan]

That looks like a good solution. I wonder if defining the newer Qt::SkipEmptyParts in older Qt would work too.

[Herrie82]

Qt::SkipEmptyParts

All depends on how plain vanilla your Qt is or you used a patched version. I guess I know the answer. An additional patch wouldn't hurt in that case.

[edit]
Though patching QtBase would make it SFOS specific and would break others using Qt5 and sensorfw (not sure if there are any though)
[/edit]

[spiiroin]

I'm sure there are other solutions too

As the split args are always the same, using internal to sensorfwd helper function comes to mind. That would leave the API level differentation a) directly observable without need to know/find/ponder about some nonstandard custom values and b) still contained in just one place. Something like ...

QStringList needsSensibleName(const QString &string)
{
#if QT_VERSION >= QT_VERSION_CHECK(x, y, z)
    return string.split(":", Qt::SkipEmptyParts);
#else
    return string.split(":", QString::SkipEmptyParts);
#endif
}

[jmlich]

I personally prefer using the way is it is currently in pull request

[spiiroin]

I personally prefer using the way is it is currently in pull request

IMO it also is just fine as it is. It makes the sw buildable with qt6 which is a clear improvement. Any further cleanup/refactoring/whatnot can be done separately by somebody else too.

@Thaodan do you still have some objections?

[Herrie82]

FWIW I'm impartial to either solution. There are pro's and cons for both to be honest. Most important is that the code works in both Qt5 and Qt6 :)

[rainemak]

FWIW I'm impartial to either solution. There are pro's and cons for both to be honest. Most important is that the code works in both Qt5 and Qt6 :)

Yes, I agree with that and changes in general look good now. Thank you @jmlich !

[rainemak]

Approving as well.

[Thaodan]

I personally prefer using the way is it is currently in pull request

IMO it also is just fine as it is. It makes the sw buildable with qt6 which is a clear improvement. Any further cleanup/refactoring/whatnot can be done separately by somebody else too.

@Thaodan do you still have some objections?

No issues, fine by me just no time to reply.