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 g...@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?
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.
Now, the question is if we want Grantlee to be backwards-compatible after the
move into KDE Frameworks, or if some breakage is possible?
When it comes to CMake targets & modules, the first challenge is:
Grantlee5 supports components, "Templates" & "TextDocument". To allow people
doing e.g.
--- 8< ---
find_package(Grantlee5 CONFIG COMPONENTS Templates)
--- 8< ---
So when Grantlee becomes a component in KF5 itself, so people would use for
finding it
--- 8< ---
find_package(KF5 CONFIG COMPONENTS Grantlee)
--- 8< ---
these two, "Templates" & "TextDocument", would need to become subcomponents.
Which though is a concept CMake does not support.
So what to do here? Split Grantlee into two separate libs, with separate CMake
config files? Done by KF5NewStuff, where one repo provides 2 separate configs.
Or just merge and do not allow making dep chain more narrow (Grantlee's
TextDocument pulls in QtGui as dep, so fails if no devel package not present)?
Then Grantlee's CMake module brings two namespaced imported targets:
* Grantlee5::Templates
* Grantlee5::TextDocument
With Grantlee being part of KDE Frameworks, one would expect to have targets
named like
* KF5::GrantleeTemplates
* KF5::GrantleeTextDocument
or similar.
I'm fine with any of this kind of stuff in the KF6 timeframe.
Just, seems CMake does not expect the use case of exporting targets with
different names, there is only one property available to set the base name,
cmp. current
--- 8< ---
set_property(TARGET Grantlee_Templates PROPERTY EXPORT_NAME Templates)
--- 8< ---
So when wanting to keep backward compatibility, we are stuck here with the old
basenames.
Do you know any simple trick to have a separate CMake config file with
separate imported targets, which still refer to the same library executable?
Never done myself, so no idea what could be done. Doing a separate target and
exporting that one will fail possibly once trying to set OUTPUT_NAME property
to the same,
Perhaps one could do a manual cmake config file which has the old one as
find_dependency and then defines an alias target on the imported target?
I don't think any of this matters in the KF6 timeframe.
Thanks,
Stephen.
