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

[Volker Krause]

On Sunday, 22 December 2019 09:46:02 CET Dominik Haumann wrote:
> Hi all,
> 
> in any case, maybe the discussed points should go to the KF6 workboard?
> https://phabricator.kde.org/project/view/310/
> 
> I indeed believe that consistency in the KF5 world is an important feature,
> so Friedrich does have a point here. Other framework additions had to adapt
> as well (what comes to my mind is renaming of KQuickCharts or
> KCalendarCore).

There is one important difference between KCalendarCore/KQuickCharts/etc and 
Grantlee/QKeychain/etc though. The former had no previous release promising a 
public API and therefore only KDE-internal users. The latter have such 
releases and guarantees, and a significant KDE-external user base. That's what 
makes me consider a transitional pragmatic exemption from certain conventions, 
if we assume it would help to grow our external user base, and thus the pool 
of potential contributors.
 
> Whatever decision is made here, imho there should/must be the objective to
> get it fixed for KF6.

Absolutely.

Regards,
Volker

> Best regards
> Dominik
> 
> Friedrich W. H. Kossebau <kossebau at kde.org> schrieb am So., 22. Dez. 2019,
> 
> 00:55:
> > 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20191223/7d783ace/attachment.sig>