Guidelins for one codebase that builds with Qt5 and Qt6?

[Halla Rempt]

On maandag 5 augustus 2024 18:49:52 CEST Tobias Leupold wrote:
> E-Mail von Halla Rempt vom Montag, 5. August 2024, 16:15:19 MESZ:
> > Hi,
> > 
> > We're finally working on porting Krita to Qt6, but that's going to be a long
> > road. I seem to remember that there were KDE apps that could be built with
> > both Qt6/Kf6 and Qt5/Kf5. Did I remember that right? And if so, is there
> > some howto or documentation for that?
> > 
> > Thanks,
> > 
> > Halla
> 
> Hi,
> 
> for https://invent.kde.org/tleupold/scandoc , I just set a "QT6" cmake switch 
> (on/off) to decide if a Qt 5 or a Qt 6 build should be done. Just look at the 
> CMakeFiles.txt, it's quite easy this way (I also do this exactly like that for 
> https://muckturnier.org/ ; that's Qt-only, no KF, but after all, it's the same 
> approach).

I think I'll take that approach.

> I think this depends on how much effort it would be to support both versions. 
> For Scandoc, it wasn't much, so I decided to support Qt/KF 5 and 6 for now. 
> That's also what I think I'll do for KGeoTag, once Marble will be ported to Qt 
> 6.
> 
> If it's a lot of work and/or manpower is limited (it's always, isn't it?!) it 
> may be better to do a Qt-6-only port. That's what we're just doing for 
> KPhotoAlbum.

That's what I tried at first, but it soon became clear that while actual porting is mostly mechanical, making Krita actually work with Qt6 is going to be a long process. We cannot afford to not be able to release Krita again for half a year or longer, so we have to find a way to keep releasing a working Krita while keeping the Qt6 port up to date in the face of huge projects like the text shape refactoring.

> 
> I don't think there's some official guideline about this, no?
> 
> Cheers, Tobias
> 
> 
>