On Thursday 31 October 2013, David Faure wrote: > On Thursday 31 October 2013 17:54:06 Alexander Neundorf wrote: > > IOW, those three files exist only for KF5, and no other reason. > > This contradicts "use KDECMakeSettings.cmake in gammaray if you want > automatic RPATH handling" as you told me some time ago. > > In other words, these things are convenience on top of cmake, not only > useful for KF5.
Let me explain how I see things. Up to KDE4, things were simple. There was the kdelibs module. It was released together, dependencies within it were ok, it was hosted on KDE infrastructure and developed by KDE people. Software using that used "KDE". With frameworks things are becoming in my view very different. Every library will be in a separate repository. What makes e.g. karchive a KF5 tier1 library and not just some library using Qt, like e.g. Qwt ? There is no clear *technical* difference. There are let's say organizational differences: it is hosted on KDE servers, it is developed by people with KDE accounts, it is (not quite sure about this) released together with a whole bunch of other libraries, it follows KDE best practices and it has the stamp "KF5" on it, given by people with KDE accounts. So, as you say that e.g. KDECMakeSettings.cmake can be used also by "non-KF5" software, the same is true for every tier1 library. We could ask for a lot if not all tier1 libraries why aren't they upstreamed into Qt ? What does e-c-m contain today: a bunch of find-modules and generic macros, which are useful for some packages, wether they use Qt or not. Additionally, KDEInstallDirs.cmake, KDECMakeSettings.cmake and KDECompilerSettings.cmake. As a fact, all KF5 frameworks on these three files, including the tier1 libs. All KF5 software could technically also be compiled and linked without these three files. So why does everything use them ? They are used to follow "KDE best practices". KDEInstallDirs.cmake is used to provide a common and complete set of install location variables, to make sure KDE developers find a common cmake environment when looking at other KDE projects. Projects which don't have the requirement that it should be easy for KDE developers to work on them have no need to use this file. They can use GNUInstallDirs.cmake, or even hardcode install locations. This would not be ok for KDE software, since we have requirements for portability etc., but it may be ok for other projects. The same for KDECompilerSettings.cmake. It is used to make KDE software build in all platforms KDE supports, with the compiler features needed by KDE. KDECMakeSettings.cmake is there to provide a set of cmake settings, again to give KDE developers a common setup where they don't have to care much about other things themselves. So all three files are there for the convenience of KDE developers, to make the projects follow KDE requirements and best practices, and their content is governed by what is considered useful by KDE developers for KDE (e.g. at work we need different RPATH settings). So here's my ideal view of the world, which clashes with the rule that there must not be a tier0: Upstream: Qt and CMake ECM: hosted somewhere, e.g. on github, contains find-modules and generic macros, not only KDE-developers contribute, it is released frequently, e.g. monthly. Required by packages which need some of the contained files, i.e. not necessarily used by all KF5 or all KDE packages, but OTOH used also by non-KDE and non-Qt packages. [1] [For the packages below, development is governed exclusively by KDE developers, which is not the case for the packages above.] tier0: kf5-build-files (or some name): Stephens KF5Config.cmake, additionally containing the three KDE*.cmake files mentioned above. Hosted by KDE. All KF5 packages, including tier1, depend on it for building. Released coordinated with the rest of KF5. So I agree with Stephen that it is the correct thing to have the KF5 umbrella cmake file in a separate package. But I would have made that tier0. tier1, 2, 3: they all depend at buildtime on tier0. Beside that, everything as we know it. To get back to Gammaray: with this view, there is no contradiction. By using KDECMakeSettings.cmake, Gammaray would simply be a user of the tier0 KF5 framework. Alex [1] Why not merge that into CMake ? For quicker releases, and even easier contributing. Also Bill once said that in hindsight he would have prefered if cmake would not ship any find-modules itself at all. So one could imagine that cmake would come without any find-modules in the future, and all find-modules would come from a separate package, e.g. ECM. This would make cmake the core tool, and ECM its "standard library". _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
