building KF5 projects against a different Qt5 version (than the one the KF5 frameworks were built against)

[David Faure]

On Saturday, April 25, 2020 2:23:34 PM CEST René J.V. Bertin wrote:
> Hi,
> 
> A priori Qt guarantees that you can run binaries against a different, newer
> Qt version than they were built against, as long as no private APIs are
> used. This also works if that newer Qt version is installed elsewhere,
> provided you set LD_LIBRARY_PATH correctly 

Yes.

> (and possibly LD_PRELOAD).

I don't see why you would set LD_PRELOAD in this configuration.

> I think this also means you can build code against such a newer (test) Qt
> install even if that code uses libraries which were built against the older
> Qt version (as long as no mixups occur at runtime; I've done this
> successfully with code that uses Phonon, for instance).

Yes when Qt itself is upgraded to a newer version.
Switching between two Qt prefixes at cmake time is another issue though,
which seems to be what you're experiencing.

> I'm not having a lot of luck building code that uses KF5 frameworks this
> way. Even after getting cmake to find the intended newer Qt version I still
> get header conflicts because something inserts unwanted header search
> paths.

I think this is because the KF5 target brings its own include paths as part of 
the imported target.

> I don't expect there to be official support for this kind of tricky things.
> Still, testing code against a new Qt version installed in parallel doesn't
> seem to be such an usual thing to do so if there is a trick to this I'd
> love to hear it.

Build against the old Qt, run against the new Qt?
Then it's back to "only" LD_LIBRARY_PATH switcheroo which works well, while at 
the buildsystem level it's all based upon the old Qt so no mixup there.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5