CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

[Friedrich W. H. Kossebau]

Am Samstag, 21. Dezember 2019, 23:32:10 CET schrieb Stephen Kelly:
> On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote:
> > Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> >> Great, Grantlee is now available at git at git.kde.org:grantlee.git.
> >> 
> >> I've pushed a few commits to make it depend on ECM etc.
> >> 
> >> Once the review period is finished it can be part of KF5 releases.
> > 
> > There are quite some things which yet need to be done for now:
> > to be a true KF module there is a set of policies which needs to be met,
> > see https://community.kde.org/Frameworks/Policies
> > 
> > 1) Framework directory structure:
> >     moving stuff into src/, autotests/ & docs/
> > 
> > 2) Framework documentation:
> >     current system needs adaption to both online (KApiDox) and
> >     offline (ECMAddQCH) systems
> 
> Cool, I wonder if there's another multi-library framework for comparison?

With ECMAddQCH, Sonnet & KNewStuff create separate QCH files for their 
multiple libs.

With KApiDox, IIRC it has the assumption 1 module <=> 1 documentation unit 
(not involved there),
Olivier (cc:ed) should be able to hint you what is possible.

> > Another challenge would be moving into the KF5 namespace for the library
> > artifacts (at least I would expect/recommend this to happen, for
> > consistent
> > user experience)
> > a) include dirs below subdir KF5/
> > b) CMake modules with KF5 prefix
> > c) CMake imported target in KF5 namespace
> 
> I don't support changing things like this in the KF5 timeframe.

IMHO not sharing the namespace "KF5" spoils the story of KDE Frameworks, where 
the namespace gives consistent developer experience and product messaging.

Having Grantlee being a special kid, with unregular CMake modules names and 
differently namespace imported CMake targets, makes things more complex.

Being consistent is what we so like about Qt, and KF should not stay behind, 
no?

Perhaps joining the "Release Service" (formerly known as "KDE Applications") 
is a better place then, it also contains a set of libraries already.
That would serve the purpose of having releases happening regularly.

Cheers
Friedrich