Usage of KF5/KF6 in targets and CMake config files outside of Frameworks

2023-03-09 Thread Heiko Becker

Hi,

while looking at a MR for libkcddb (part of Gear) I wondered if the 
transition
from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 prefix in 
target
names and CMake config files for libraries that aren't acutally part of 
Frameworks.


It always seemed a bit illogical and possibly confusing to me to have e.g. 
KF5Cddb as CMake config file and KF5::Cddb as target name, because it's  
masquerading to be part of something (Frameworks), which isn't actually 
true.
Especially since we market Frameworks as a common group of libraries, with 
common rules and policies, which may only be followed in part (or maybe not 
at all) by other projects.


Changing that obviously involves some (temporary) compatibility concerns, 
but that doesn't play any role with the move to Qt6/KF6. So I suggest to 
use the chance and get rid of said prefix with the upcoming porting.


One example where this was done already some time ago is libkgapi: 
https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888b7f924a49


Regards,
Heiko


Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks

2023-03-09 Thread Volker Krause
On Thursday, 9 March 2023 16:58:40 CET Heiko Becker wrote:
> while looking at a MR for libkcddb (part of Gear) I wondered if the
> transition
> from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 prefix in
> target
> names and CMake config files for libraries that aren't acutally part of
> Frameworks.
> 
> It always seemed a bit illogical and possibly confusing to me to have e.g.
> KF5Cddb as CMake config file and KF5::Cddb as target name, because it's
> masquerading to be part of something (Frameworks), which isn't actually
> true.
> Especially since we market Frameworks as a common group of libraries, with
> common rules and policies, which may only be followed in part (or maybe not
> at all) by other projects.
> 
> Changing that obviously involves some (temporary) compatibility concerns,
> but that doesn't play any role with the move to Qt6/KF6. So I suggest to
> use the chance and get rid of said prefix with the upcoming porting.
> 
> One example where this was done already some time ago is libkgapi:
> https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888
> b7f924a49

... and much more recently in a number of other PIM modules as well.

My impression so far was that it's already largely consensus that using the KF 
prefix outside of Frameworks was a mistake we made in the early 5 days, and 
that should be corrected when the opportunity arises.

There is one possible exception I can see for this, libraries with an imminent 
move to Frameworks. We have used the fact those were already using the KF 
prefix in several cases (e.g. KContact, KCalendarCore, KDAV) for a seamless 
switch from Gear to Frameworks. Many of the remaining users don't fall into 
that category though.

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.


Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks

2023-03-09 Thread Ingo Klöcker
On Donnerstag, 9. März 2023 16:58:40 CET Heiko Becker wrote:
> while looking at a MR for libkcddb (part of Gear) I wondered if the
> transition
> from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 prefix in
> target
> names and CMake config files for libraries that aren't acutally part of
> Frameworks.

+1

> Changing that obviously involves some (temporary) compatibility concerns,
> but that doesn't play any role with the move to Qt6/KF6. So I suggest to
> use the chance and get rid of said prefix with the upcoming porting.
> 
> One example where this was done already some time ago is libkgapi:
> https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e24888
> b7f924a49

This is a particular bad example because it changes the name of the Qt5 
version breaking all existing Qt5-based users instead of just fixing the name 
for Qt6/KF6. (Yes, this KDE PIM library isn't public API, so it doesn't hurt 
external users. But it has cost me many hours compiling libraries from source 
where I previously could always use the distribution packages). Please don't 
follow this annoying example.

Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.


Re: Usage of KF5/KF6 in targets and CMake config files outside of Frameworks

2023-03-09 Thread Friedrich W. H. Kossebau
Am Donnerstag, 9. März 2023, 18:03:17 CET schrieb Ingo Klöcker:
> On Donnerstag, 9. März 2023 16:58:40 CET Heiko Becker wrote:
> > while looking at a MR for libkcddb (part of Gear) I wondered if the
> > transition
> > from Qt5/KF5 to Qt6/KF6 could be used to get rid of the KF5/6 prefix in
> > target
> > names and CMake config files for libraries that aren't acutally part of
> > Frameworks.
> 
> +1

+1 

> > Changing that obviously involves some (temporary) compatibility concerns,
> > but that doesn't play any role with the move to Qt6/KF6. So I suggest to
> > use the chance and get rid of said prefix with the upcoming porting.
> > 
> > One example where this was done already some time ago is libkgapi:
> > https://invent.kde.org/pim/libkgapi/-/commit/8d15e66f1ed87a52377111735e248
> > 88 b7f924a49
> 
> This is a particular bad example because it changes the name of the Qt5
> version breaking all existing Qt5-based users instead of just fixing the
> name for Qt6/KF6. (Yes, this KDE PIM library isn't public API, so it
> doesn't hurt external users. But it has cost me many hours compiling
> libraries from source where I previously could always use the distribution
> packages). Please don't follow this annoying example.

+1 (as in, we should stick to what is proposed, use the 5->6 breakage to also 
funnel other nice-to-finally-do breakages into it)

Did some related MRs now for libkmahjongg, for some other example:
https://invent.kde.org/games/libkmahjongg/-/merge_requests/9
Adaption consumer side:
https://invent.kde.org/games/kmahjongg/-/merge_requests/21

Cheers
Friedrich