Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On Mon, Dec 30, 2019 at 3:03 AM Stephen Kelly wrote: > > > On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote: > > Why are you proposing to do a step back instead to the old state, which > > everyone including you considered not that satisfying? > > Because it's a temporary situation. We still have a way forward in KF6 > (which will open in a few months). I have now actioned the reversal. As this has cost a reasonable amount of time (and the full fallout of the reversal has yet to be felt, with the CI rebuild yet to come which I anticipate is going to require additional time on my part to sort out), i'm going to require that the Grantlee project on Github be transferred to KDE as part of the KF6 move (and this transfer will take place prior to any infrastructure being setup on our side) > > > Generally, getting Grantlee into KF5 now also establishes the wrong > precedent. Grantlee should be split into two repos each with a tier 1 > library (KF6::TextDocument and KF6::TextTemplate). The two are > independent and have nothing to do with each other aside from > authorship. That seems to be something you were objecting to, so I want > to make sure that's something addressed on its own. The two KF6 > libraries will then follow the KF6 naming conventions etc. > > > > I hope my personal objections raised about it becoming an official KF module > > already now have not arrived with you as objection in general. > > > Not at all. I agree that the two libraries should be consistent with the > rest of the Frameworks. > > > > On the > > opposite, I agree with the ideas behind this move. I have just strict > > feeling > > about KF as a product itself when it comes to consumer as well as > > cross-module > > ontributor experience. > > So please be aware that I would be sad if you decided to have Grantlee go > > back > > to lonely cowboy mode :) > > > Only temporarily :). > > Thanks, > > Stephen. > > Regards, Ben
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
Hi, Stephen Kelly schrieb am So., 29. Dez. 2019, 15:03: > > On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote: > > Why are you proposing to do a step back instead to the old state, which > > everyone including you considered not that satisfying? > > Because it's a temporary situation. We still have a way forward in KF6 > (which will open in a few months). > > > Generally, getting Grantlee into KF5 now also establishes the wrong > precedent. Grantlee should be split into two repos each with a tier 1 > library (KF6::TextDocument and KF6::TextTemplate). The two are > independent and have nothing to do with each other aside from > authorship. That seems to be something you were objecting to, so I want > to make sure that's something addressed on its own. The two KF6 > libraries will then follow the KF6 naming conventions etc. > With my KTextEditor hat on: KF6:TextDocument implies somehow a link to QTextDocument or KF6:TextEditor, which both is incorrect, right? Before starting this work, let's clarify whether we can find a more unique name (like KF6:GrantleeTextDocument). Since I haven't used Grantlee yet, I sm likely not the best person to find a better name ;) Best regards Dominik >
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote: Why are you proposing to do a step back instead to the old state, which everyone including you considered not that satisfying? Because it's a temporary situation. We still have a way forward in KF6 (which will open in a few months). Generally, getting Grantlee into KF5 now also establishes the wrong precedent. Grantlee should be split into two repos each with a tier 1 library (KF6::TextDocument and KF6::TextTemplate). The two are independent and have nothing to do with each other aside from authorship. That seems to be something you were objecting to, so I want to make sure that's something addressed on its own. The two KF6 libraries will then follow the KF6 naming conventions etc. I hope my personal objections raised about it becoming an official KF module already now have not arrived with you as objection in general. Not at all. I agree that the two libraries should be consistent with the rest of the Frameworks. On the opposite, I agree with the ideas behind this move. I have just strict feeling about KF as a product itself when it comes to consumer as well as cross-module ontributor experience. So please be aware that I would be sad if you decided to have Grantlee go back to lonely cowboy mode :) Only temporarily :). Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
Hi Stephen, Am Sonntag, 29. Dezember 2019, 00:10:50 CET schrieb Stephen Kelly: > On 22/12/2019 16:08, Stephen Kelly wrote: > > On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote: > >> 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. > > > > The goals of making Grantlee a Framework are: > > > > * Make more frequent releases which don't depend on me > > > > * Make it more easy for others to contribute to development > > > > > > I think at the point that renaming happens, the name Grantlee will > > disappear, and we'll have two libraries (KF5::TextDocument and > > KF5::TextTemplates or so in CMake and probably removing the C++ > > namespace). > > > > I think all of that should be done together and I don't think that > > should be done until compatibility is broken to become Qt6-based (KF6). > > My conclusion from reading this thread is that this is the way forward: > > * Grantlee does not become a KF5 framework. I'll continue to make > releases from github if needed based on Qt 5. We can consider > re-evaluating that in the future. Not becoming a KF5 module should not stop you/us making Grantlee a project now developed in the KDE community. Given your two goals cited above, making Grantlee hosted on KDE resources and releasing it as part of the "release service" should satisfy your goals already now. And it would allow to make Grantlee already now move as close enough as possible to KF standards, besides the naming ones. So that at KF6 time only those things are left to do both on producer & consumer side which are about ABI breakage. Why are you proposing to do a step back instead to the old state, which everyone including you considered not that satisfying? I hope my personal objections raised about it becoming an official KF module already now have not arrived with you as objection in general. On the opposite, I agree with the ideas behind this move. I have just strict feeling about KF as a product itself when it comes to consumer as well as cross-module ontributor experience. So please be aware that I would be sad if you decided to have Grantlee go back to lonely cowboy mode :) Cheers Friedrich
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 22/12/2019 16:08, Stephen Kelly wrote: On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote: 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. The goals of making Grantlee a Framework are: * Make more frequent releases which don't depend on me * Make it more easy for others to contribute to development I think at the point that renaming happens, the name Grantlee will disappear, and we'll have two libraries (KF5::TextDocument and KF5::TextTemplates or so in CMake and probably removing the C++ namespace). I think all of that should be done together and I don't think that should be done until compatibility is broken to become Qt6-based (KF6). My conclusion from reading this thread is that this is the way forward: * Grantlee does not become a KF5 framework. I'll continue to make releases from github if needed based on Qt 5. We can consider re-evaluating that in the future. * For KF6, I will submit two separate Tier 1 frameworks, in two different repos, what I here called ktextdocument/KF6::TextDocument and ktexttemplate/KF6::TextTemplate The two libraries are independent. Having them in the same KF* repo doesn't make sense. Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
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 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 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? > > > > 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 signature.asc Description: This is a digitally signed message part.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
Am Sonntag, 22. Dezember 2019, 17:08:15 CET schrieb Stephen Kelly: > On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote: > > 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. > The goals of making Grantlee a Framework are: > > * Make more frequent releases which don't depend on me > > * Make it more easy for others to contribute to development > > > I think at the point that renaming happens, the name Grantlee will > disappear, and we'll have two libraries (KF5::TextDocument and > KF5::TextTemplates or so in CMake and probably removing the C++ namespace). There is no need to drop the name "Grantlee", IMHO that is a well-known product/solution identifier by now for the needs it solves. There are other non-generic-name identifiers in KDE Frameworks (Sonnet, Purpose, Prison, Attica, Solid, Baloo, Syndication) instead of "K" + generic descriptive english name, so it is also nothing new in concept. KF5::TextDocument & KF5::TextTemplates as target/lib names e.g. would be less useful, as they could describe a lot of things and would need to be longer to be more exact :) So having "Grantlee" as easily searchable term which also is properly defined what solution scope it is about can be actually seen as an advantage. > I think all of that should be done together and I don't think that > should be done until compatibility is broken to become Qt6-based (KF6). > > If joining the Release Service helps reach the goals, and there is > consensus that Grantlee can't be a framework without partial renaming > (ie renaming the CMake interface but little else) in KF5, then that > might be the way to go. So far I was hoping we could have both for KF5 already, backward-compatible CMake config files with old imported targets as well as parallel new KF5- namespaced CMake names. Myself still no good idea how to do this in CMake without too much manual complicated fragile hackery. Cheers Friedrich
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote: 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. The goals of making Grantlee a Framework are: * Make more frequent releases which don't depend on me * Make it more easy for others to contribute to development I think at the point that renaming happens, the name Grantlee will disappear, and we'll have two libraries (KF5::TextDocument and KF5::TextTemplates or so in CMake and probably removing the C++ namespace). I think all of that should be done together and I don't think that should be done until compatibility is broken to become Qt6-based (KF6). If joining the Release Service helps reach the goals, and there is consensus that Grantlee can't be a framework without partial renaming (ie renaming the CMake interface but little else) in KF5, then that might be the way to go. Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
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). Whatever decision is made here, imho there should/must be the objective to get it fixed for KF6. Best regards Dominik Friedrich W. H. Kossebau 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 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? > > 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 > > >
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
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 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? 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
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
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.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On 21/12/2019 21:33, Volker Krause wrote: * Attracting external components and having them opt to move under the Frameworks umbrella is a sign that we are doing things right IMHO. So let's make this easy for people and avoid scaring off their users by forcing a larger migration on them when joining Frameworks. I definitely want to keep things as they are. Grantlee has lots of users. The mutual advantages of making Grantlee a KF5 Framework without changing how it's used in CMake (aside from a few minor details like the fact of the ECM dependency) are what makes KF5 attractive. * We are less than two years away from KF6, a time where people expect to have to do a larger migration anyway. Deferring some of the necessary changes to then might be a compromise that works for now. This seems like the right way to me. Let's make the fundamental changes for KF6. The timing of KF6 and the introduction of Grantlee to KF5 are favorable to that. Another option is to skip KF5 and make Grantlee a KF6 frameworks whenever that opens. Thoughts? Thanks, Volker PS: @Steve: I missed the doxygen discussion on IRC earlier, customizing doxygen is possible via docs/Doxyfile.local, which just gets appended to the Doxyfile from kapidox IIUC, maybe that helps already? Cool, I'll look into it. Thanks, Stephen.
Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
On Saturday, 21 December 2019 20:12:48 CET 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 > > I could do 1) if you like, and help with 2) on the ECMAddQCH part. > > 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 > > 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. > > 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? Backward compatibility with new frameworks coming in with an existing internal and external user base is a good question though, this also came up with QKeychain recently. That is, do we break ABI/API as part of the inclusion into Frameworks, to make them fully comply with all Framework policies, or do we allow for exemptions for the current major release in this case? Ultimately it's a tradeoff between ease of migration for existing code bases (which aren't just our own, but also those of the users the new framework brings in), and consistency in Frameworks. I'm undecided on this myself still: * Consistency is an important part of the Frameworks product story (even if we aren't perfectly following this everywhere). * Attracting external components and having them opt to move under the Frameworks umbrella is a sign that we are doing things right IMHO. So let's make this easy for people and avoid scaring off their users by forcing a larger migration on them when joining Frameworks. * We are less than two years away from KF6, a time where people expect to have to do a larger migration anyway. Deferring some of the necessary changes to then might be a compromise that works for now. Thoughts? Thanks, Volker PS: @Steve: I missed the doxygen discussion on IRC earlier, customizing doxygen is possible via docs/Doxyfile.local, which just gets appended to the Doxyfile from kapidox IIUC, maybe that helps already? signature.asc Description: This is a digitally signed message part.
CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)
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 I could do 1) if you like, and help with 2) on the ECMAddQCH part. 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 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. 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? Cheers Friedrich
