> On Sept. 26, 2013, 8:27 p.m., Alexander Neundorf wrote: > > template/CMakeLists.txt, line 22 > > <http://git.reviewboard.kde.org/r/112928/diff/5/?file=192796#file192796line22> > > > > The idea here was that you can simply list all required KF5 frameworks > > in one find_package() call: > > find_package(KF5 COMPONENTS CMake Compiler InstallDirs KCoreAddons > > Solid ....) > > > > When not doing this, you can also use the longer include() syntax > > instead of the find_package(KF5) syntax: > > include(KDECMakeSettings) > > include(KDECompilerSettings) > > include(KDEInstallDirs) > > find_package(KCoreAddons) > > > > Stephen Kelly wrote: > What would make sense to me is this: > > As a downstream KDE application > find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) > find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) > > As a downstream which is not a KDE application: > find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) > > In the KF5 tier1 buildsystems: > find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) > > In the KF5 tier>1 buildsystems: > find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) > find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) > > That way, when we're building KF5 tier1, we're not finding KF5. We're > finding and using ECM. > > When we're building KF5 tier2, we're finding out tier1 deps and we're > finding and using ECM. > > etc. > > That maps to reality. It's a bit unfortunate that find_package(KF5) has > to be a FindKF5 in ECM, but that's ok IMO. > > Thanks, > > Steve. > > Aurélien Gâteau wrote: > Alexander: I am still not sure what the arguments after REQUIRED are, I > just cargo-culted them. Are you saying this is just a way to avoid adding > include() lines? If so, how comes the arguments after REQUIRED are not > exactly the same as the one you used in your include() lines? > > Steve: this sounds good to me, but would be tricky to keep readable if we > fit all in one template file. Maybe it would be better to create different > templates, like templates/tier1, templates/tiern, templates/kde-app, > templates/qt-app? I am worried about the templates bit-rotting though. > > Stephen Kelly wrote: > My comment was more about what is maintained in the repos and what I find > readable and what I think maps to reality. My comment was not spefically > about what a template-based generator would generate. After being generated > from a template the code will have to be changed and maintained anyway. > > I'd put a comment in the single template that you have, not create > multiple templates. That would only have people wondering what to use. Note > though that what I said would make sense to me is not the current state. > > Aurélien Gâteau wrote: > Oh OK. Actually, I would not put instructions for application in there, > just tier1 and tier N+1. Application instructions should be kept somewhere > else IMO. > > Alexander Neundorf wrote: > find_package(ECM 0.0.9 REQUIRED KDECMake KDECompiler KDEInstallDirs) > find_package(KF5 5.0.0 REQUIRED KCoreAddons Solid) > > I see what you mean. > Still, when starting that way, i.e. making KDECMake etc. components of > ECM, then all other find-modules of ECM could in the same way be considered > components of ECM. > As I see it, they belong to KDE, at least logically, so they are part of > KDE frameworks. > > Alexander Neundorf wrote: > Aurelien: the component keywords are evaluated by FindKF5.cmake, which > translates them internally into the real filenames. If you simply use > include(), you have to use the real filenames. > They differ just so it is less to write/looks prettier: > find_package(KF5 COMPONENTS CMake Compiler InstallDirs Solid ...) > instead of > find_package(KF5 COMPONENTS KDECMakeSettings KDECompilerSettings > KDEInstallDirs Solid ...) > > The components are anyway already "namespaced" by being part of the > find_package() call for KF5. >
Stephen: and what I forgot: technically, "KDECMake" would be a component of ECM, ECMConfig.cmake would have to contain code for these KDE-files. I did not want that. As it is, all the KDE-specific stuff is nicely separated in the kde-modules/ folder. And yes, a separate "these are the cmake files specific for KDE and nothing else" package would have been cleaner. - Alexander ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112928/#review40893 ----------------------------------------------------------- On Sept. 27, 2013, 3:05 p.m., Aurélien Gâteau wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112928/ > ----------------------------------------------------------- > > (Updated Sept. 27, 2013, 3:05 p.m.) > > > Review request for KDE Frameworks, Kevin Ottens, Alexander Neundorf, and > Stephen Kelly. > > > Description > ------- > > This patch adds a template/ dir which contains example CMakeLists.txt and > FooBarConfig.cmake.in files, based on what exists in current frameworks. > > > Diffs > ----- > > template/CMakeLists.txt PRE-CREATION > template/FooBarConfig.cmake.in PRE-CREATION > template/autotests/CMakeLists.txt PRE-CREATION > template/setup.sh PRE-CREATION > template/src/CMakeLists.txt PRE-CREATION > template/src/myclass.h PRE-CREATION > template/src/myclass.cpp PRE-CREATION > template/tests/CMakeLists.txt PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/112928/diff/ > > > Testing > ------- > > > Thanks, > > Aurélien Gâteau > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
