Re: Updating CMake requirement to 2.8.12 RC 1
On Friday 23 August 2013, Ben Cooksley wrote: On Fri, Aug 23, 2013 at 7:14 PM, David Faure fa...@kde.org wrote: On Friday 23 August 2013 06:51:23 Martin Graesslin wrote: Given that it's already lots of work to keep up with the constant breakage due to changes in frameworks the outlook of also having breakage in cmake is nothing I look forward to. FWIW, I've been using cmake master for many years, and I can't even remember *ONE* breakage. But anyway, I'm fine with not requiring git master, since the thread showed that it's not convenient for everyone. I just wanted to refute the argument about breakages :) I'll note that build.kde.org has picked up several regressions in the past, however these were in the CMake dev branch, which is expected to be a little bit more unstable than all the others, as it has been subject to less testing. build.kde.org should use the cmake which is required by KF5. If it additionally does builds using cmake from git that's even better. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
On Tuesday 20 August 2013, Stephen Kelly wrote:
Hello,
CMake 2.8.12 RC 1 was released a few hours ago:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/47443
Updating to that will allow us to get on the home straight with regard to
our buildsystem files.
For example, we can easily set the INTERFACE_INCLUDE_DIRECTORIES of the
targets we export. We can do that with a simple patch to
INSTALL_TARGETS_DEFAULT_ARGS in ecm:
diff --git a/kde-modules/KDEInstallDirs.cmake b/kde-
modules/KDEInstallDirs.cmake
index c3d4d7c..87370b4 100644
--- a/kde-modules/KDEInstallDirs.cmake
+++ b/kde-modules/KDEInstallDirs.cmake
@@ -173,7 +173,8 @@ _set_fancy(DBUS_SYSTEM_SERVICES_INSTALL_DIR
${SHARE_INSTALL_PREFIX}/dbus-1/syst
# This can then also be used for packaging with cpack.
set(INSTALL_TARGETS_DEFAULT_ARGS RUNTIME DESTINATION ${BIN_INSTALL_DIR}
LIBRARY DESTINATION ${LIB_INSTALL_DIR}
- ARCHIVE DESTINATION ${LIB_INSTALL_DIR})
+ ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
+ INCLUDES DESTINATION ${INCLUDE_INSTALL_DIR})
${INCLUDE_INSTALL_DIR} can be both an absolute or a relative path.
Does this support both ?
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
On Wed, Aug 28, 2013 at 2:54 AM, Alexander Neundorf neund...@kde.org wrote: On Friday 23 August 2013, Ben Cooksley wrote: On Fri, Aug 23, 2013 at 7:14 PM, David Faure fa...@kde.org wrote: On Friday 23 August 2013 06:51:23 Martin Graesslin wrote: Given that it's already lots of work to keep up with the constant breakage due to changes in frameworks the outlook of also having breakage in cmake is nothing I look forward to. FWIW, I've been using cmake master for many years, and I can't even remember *ONE* breakage. But anyway, I'm fine with not requiring git master, since the thread showed that it's not convenient for everyone. I just wanted to refute the argument about breakages :) I'll note that build.kde.org has picked up several regressions in the past, however these were in the CMake dev branch, which is expected to be a little bit more unstable than all the others, as it has been subject to less testing. build.kde.org should use the cmake which is required by KF5. If it additionally does builds using cmake from git that's even better. It builds it from Git, the 'next' branch to be precise. See http://build.kde.org/job/cmake/ for more information. The references to the 'master' branch should be ignored in any build log output. Builds are automatically performed once per week. We don't track the status of CMake tests, although they are executed. Alex Regards, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
On Friday 23 August 2013 06:51:23 Martin Graesslin wrote: Given that it's already lots of work to keep up with the constant breakage due to changes in frameworks the outlook of also having breakage in cmake is nothing I look forward to. FWIW, I've been using cmake master for many years, and I can't even remember *ONE* breakage. But anyway, I'm fine with not requiring git master, since the thread showed that it's not convenient for everyone. I just wanted to refute the argument about breakages :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
On Fri, Aug 23, 2013 at 7:14 PM, David Faure fa...@kde.org wrote: On Friday 23 August 2013 06:51:23 Martin Graesslin wrote: Given that it's already lots of work to keep up with the constant breakage due to changes in frameworks the outlook of also having breakage in cmake is nothing I look forward to. FWIW, I've been using cmake master for many years, and I can't even remember *ONE* breakage. But anyway, I'm fine with not requiring git master, since the thread showed that it's not convenient for everyone. I just wanted to refute the argument about breakages :) I'll note that build.kde.org has picked up several regressions in the past, however these were in the CMake dev branch, which is expected to be a little bit more unstable than all the others, as it has been subject to less testing. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 Regards, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
On Friday 23 August 2013 09:14:05 David Faure wrote: On Friday 23 August 2013 06:51:23 Martin Graesslin wrote: Given that it's already lots of work to keep up with the constant breakage due to changes in frameworks the outlook of also having breakage in cmake is nothing I look forward to. FWIW, I've been using cmake master for many years, and I can't even remember *ONE* breakage. I didn't mean that I expect cmake to break. But that I expect my build to break because something somewhere started to use new functionality not available in the cmake version I use. But anyway, I'm fine with not requiring git master, since the thread showed that it's not convenient for everyone. I just wanted to refute the argument about breakages :) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
On Wednesday 21 August 2013 08:40:43 Kevin Ottens wrote: Hello, On Tuesday 20 August 2013 23:23:30 Alexander Neundorf wrote: On Tuesday 20 August 2013, Stephen Kelly wrote: Alexander Neundorf wrote: please wait with updating the required version until 2.8.12 final is out. There have been complaints about requiring unreleased versions of cmake, e.g. by Aaron. The objections from Aaron were based partly on misunderstanding. http://thread.gmane.org/gmane.comp.kde.devel.frameworks/2339/focus=2357 For example, he complained about a 'dated snapshot', which I fixed in kdelibs.git with commit f1e6b8e67fe5071 (Add a better error message about the required CMake version., 2013-04-30). https://projects.kde.org/projects/kde/kdelibs/repository/revisions/f1e6 b8 e 67fe5071a19e9ad5b8ed8ee93fa26fc4c/diff/CMakeLists.txt Additionally, I my recommendation is not to bump the required version with each release candidate made available, only this first one, and then the final. The crux of the issue is: Is there anyone building kdelibs-frameworks and/or plasma-framework without using the kdesrc-build based procedure described on the wiki? http://community.kde.org/Frameworks/Building Because the proposed setup pulls cmake master anyway. So our contributor base will soon meet the requirements as they trigger their next build... It's much more automatic than the last time in that regard, we put the effort in that. Just to give some feedback: I did use the building steps as outlined on the wiki to setup the build directories and install directory. But since then I'm only running make from either terminal or kdevelop. This means although I have the self-compiled cmake somewhere, I'm not using it. If we depend on cmake master at least my current setup would fail requiring me to reconfigure each of my kdevelop projects to use the right cmake. Given that it's already lots of work to keep up with the constant breakage due to changes in frameworks the outlook of also having breakage in cmake is nothing I look forward to. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
Hello, On Tuesday 20 August 2013 23:23:30 Alexander Neundorf wrote: On Tuesday 20 August 2013, Stephen Kelly wrote: Alexander Neundorf wrote: please wait with updating the required version until 2.8.12 final is out. There have been complaints about requiring unreleased versions of cmake, e.g. by Aaron. The objections from Aaron were based partly on misunderstanding. http://thread.gmane.org/gmane.comp.kde.devel.frameworks/2339/focus=2357 For example, he complained about a 'dated snapshot', which I fixed in kdelibs.git with commit f1e6b8e67fe5071 (Add a better error message about the required CMake version., 2013-04-30). https://projects.kde.org/projects/kde/kdelibs/repository/revisions/f1e6b8 e 67fe5071a19e9ad5b8ed8ee93fa26fc4c/diff/CMakeLists.txt Additionally, I my recommendation is not to bump the required version with each release candidate made available, only this first one, and then the final. The crux of the issue is: Is there anyone building kdelibs-frameworks and/or plasma-framework without using the kdesrc-build based procedure described on the wiki? http://community.kde.org/Frameworks/Building Because the proposed setup pulls cmake master anyway. So our contributor base will soon meet the requirements as they trigger their next build... It's much more automatic than the last time in that regard, we put the effort in that. I also stand by the utility of bumping the requirement for the purpose of finding bugs. Otherwise 2.8.12 might be entirely unsuitable for frameworks. You know that stuff can be tested without committing changes which force everybody to update immediately to the main branch ? I've been doing that for years. I think that he meant getting a wider tester base, which in our case means updating to the main branch if I'm not mistaken. In a separate branch or using a knob you get a much smaller set of testers. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
The crux of the issue is: Is there anyone building kdelibs-frameworks and/or plasma-framework without using the kdesrc-build based procedure described on the wiki? http://community.kde.org/Frameworks/Building I don't use kdesrc-build. I primarily rely on packages from Project Neon 5 and only compile stuff that I work on ( kdelibs and Qt5 ) Even Project Neon 5 doesn't use kdesrc-build itself, so I disagree on raising the cmake requirement, at least before the final release is out. Regards Rohan Garg signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
Hello, On Wednesday 21 August 2013 11:00:56 Giorgos Tsiapaliokas wrote: On 20 August 2013 23:47, Alexander Neundorf neund...@kde.org wrote: On 21 August 2013 09:40, Kevin Ottens ervin+bluesyst...@kde.org wrote: The crux of the issue is: Is there anyone building kdelibs-frameworks and/or plasma-framework without using the kdesrc-build based procedure described on the wiki? http://community.kde.org/Frameworks/Building Because the proposed setup pulls cmake master anyway. because we use kdesrc-build, this doesn't mean that all of us compile cmake from sources. That's the theory. I'm trying to gauge in practice what the actual people working on kdelibs-frameworks and plasma-framework are doing. If you follow the wiki page I referred to earlier you already build cmake from sources for the kf5 work. Or did you mean that you're not using the kdesrc-build setup of that page? That'd actually be useful feedback for me in that discussion. I'm trying to get a sample set of who doesn't follow the content of the building page. I think that he meant getting a wider tester base, In KDE4, only released versions of the cmake are required and cmake is working. Why does this have to change in KF5? In KDE4, only released versions of Qt are required and Qt is working. Why does this have to change in KF5? :-) The reasons are the same for both really, cmake and Qt are our two main upstreams. If we'd wait for Qt 5.2 to be released we'd get nothing done on the splitting front (so we use qt5.git as a sync point). I admit it's less critical for cmake and extra-cmake-modules (which you use unreleased versions of without noticing BTW). Note we don't even talk about using a random snapshot though 2.8.12-rc1 is a released version. On 20 August 2013 23:33, Stephen Kelly steve...@gmail.com wrote: Hello, CMake 2.8.12 RC 1 was released a few hours ago: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/47443 Updating to that will allow us to get on the home straight with regard to our buildsystem files. For example, we can easily set the INTERFACE_INCLUDE_DIRECTORIES of the targets we export. We can do that with a simple patch to INSTALL_TARGETS_DEFAULT_ARGS in ecm: why we can't just wait until cmake 2.8.12 will be released? Until now we didn't have those features, why is it so urgent to use them right now? If we wait until cmake 2.8.12 will be released those new features will be added to KF5 and nobody will be *forced* to use an unreleased version of cmake. I think the idea is to give lead time to get the cmake in order for splitting without going through variables as an intermediate step. I'd like to avoid variables instead of direct targets as an end game, so going through variables as an intermediate state looks like unneeded rework to me. Now the prep work could be done in a branch until 2.8.12 is out if that's not too far in the future (long lived branches being expensive to maintain). Alex, Stephen, any idea about that? Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
Hello, On Wednesday 21 August 2013 13:37:29 Rohan Garg wrote: The crux of the issue is: Is there anyone building kdelibs-frameworks and/or plasma-framework without using the kdesrc-build based procedure described on the wiki? http://community.kde.org/Frameworks/Building I don't use kdesrc-build. I primarily rely on packages from Project Neon 5 and only compile stuff that I work on ( kdelibs and Qt5 ) Even Project Neon 5 doesn't use kdesrc-build itself, OK, that's actually an interesting data point. so I disagree on raising the cmake requirement, at least before the final release is out. Which cmake release do you use in Project Neon 5? Is it part of your packaging effort or you assume whatever comes from the distro? Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
so I disagree on raising the cmake requirement, at least before the final release is out. Which cmake release do you use in Project Neon 5? Is it part of your packaging effort or you assume whatever comes from the distro? We currently build for 2 releases last stable (Raring) and current dev (Saucy) , for Saucy we assume packages come from the distro, and for Raring we had to backport CMake 2.8.11.2 to the PPA. While KDE Frameworks is sandboxed separately from a stable KDE install, cmake is not sandboxed and overwrites the cmake package from the official distro repository., which is why I'm uneasy with thought of having a RC release of cmake in the PPA. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
Rohan Garg wrote: While KDE Frameworks is sandboxed separately from a stable KDE install, cmake is not sandboxed and overwrites the cmake package from the official distro repository., which is why I'm uneasy with thought of having a RC release of cmake in the PPA. What will be different when the 2.8.12 final is released? It will be needed for frameworks, and your cmake 2.8.12 package will still overwrite the distro version, correct? Why is it impossible to put the cmake 2.8.12 package in the same sandbox as the KDE Frameworks? Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
On Wednesday 21 August 2013 12:27:06 Stephen Kelly wrote: Rohan Garg wrote: While KDE Frameworks is sandboxed separately from a stable KDE install, cmake is not sandboxed and overwrites the cmake package from the official distro repository., which is why I'm uneasy with thought of having a RC release of cmake in the PPA. What will be different when the 2.8.12 final is released? It will be needed for frameworks, and your cmake 2.8.12 package will still overwrite the distro version, correct? Yep but from a distro package perspective I can understand not wanting to overrule with a not final release of a component. Why is it impossible to put the cmake 2.8.12 package in the same sandbox as the KDE Frameworks? That's a valid question indeed. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
Rohan Garg wrote: What will be different when the 2.8.12 final is released? It will be needed for frameworks, and your cmake 2.8.12 package will still overwrite the distro version, correct? Correct, the difference would be that instead of releasing a unstable cmake which might have bugs, we will be releasing a fairly well tested version of cmake. Who will have tested it so much that the final deserves the 'fairly well tested' label, but the RC does not? Understand that CMake release candidates are really, truly candidates for release. That label is not something time-based or simply position-in- release-cycle based. A release candidate is generally not made if there are known bugs which need to be fixed for the final release. The more I think about it, the more it seems like a chicken and egg problem : New cmake might potentially break apps, hence we don't ship it, but if the problem is never caught, it might never be corrected and the final release might still have the bug. Correct. I suppose people can always roll back to a stable release of cmake using apt if it does break their projects. Yes. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
On Wednesday, August 21, 2013 08:40:43 Kevin Ottens wrote: Is there anyone building kdelibs-frameworks and/or plasma-framework without using the kdesrc-build based procedure described on the wiki? http://community.kde.org/Frameworks/Building I am, on two systems. (Just as data point, I want to switch to kdesrc-build, but haven't done so.) My opinion: requiring übernew versions of cmake makes contributing harder, and we should try to avoid that if the advantage does not greatly outweigh that. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
On Wednesday 21 August 2013, Kevin Ottens wrote: Hello, On Tuesday 20 August 2013 23:23:30 Alexander Neundorf wrote: On Tuesday 20 August 2013, Stephen Kelly wrote: Alexander Neundorf wrote: please wait with updating the required version until 2.8.12 final is out. There have been complaints about requiring unreleased versions of cmake, e.g. by Aaron. The objections from Aaron were based partly on misunderstanding. http://thread.gmane.org/gmane.comp.kde.devel.frameworks/2339/focus=235 7 For example, he complained about a 'dated snapshot', which I fixed in kdelibs.git with commit f1e6b8e67fe5071 (Add a better error message about the required CMake version., 2013-04-30). https://projects.kde.org/projects/kde/kdelibs/repository/revisions/f1e 6b8 e 67fe5071a19e9ad5b8ed8ee93fa26fc4c/diff/CMakeLists.txt Additionally, I my recommendation is not to bump the required version with each release candidate made available, only this first one, and then the final. The crux of the issue is: Is there anyone building kdelibs-frameworks and/or plasma-framework without using the kdesrc-build based procedure described on the wiki? http://community.kde.org/Frameworks/Building Because the proposed setup pulls cmake master anyway. I know that this is the case, but I don't know why. I am not aware of the proposal or discussion to rely on cmake master. (I remember that there were some emails that jenkins didn't build and somebody fixed the scripts in some way, but this is not a proposal let's require cmake git master now). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Updating CMake requirement to 2.8.12 RC 1
Hello,
CMake 2.8.12 RC 1 was released a few hours ago:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/47443
Updating to that will allow us to get on the home straight with regard to
our buildsystem files.
For example, we can easily set the INTERFACE_INCLUDE_DIRECTORIES of the
targets we export. We can do that with a simple patch to
INSTALL_TARGETS_DEFAULT_ARGS in ecm:
diff --git a/kde-modules/KDEInstallDirs.cmake b/kde-
modules/KDEInstallDirs.cmake
index c3d4d7c..87370b4 100644
--- a/kde-modules/KDEInstallDirs.cmake
+++ b/kde-modules/KDEInstallDirs.cmake
@@ -173,7 +173,8 @@ _set_fancy(DBUS_SYSTEM_SERVICES_INSTALL_DIR
${SHARE_INSTALL_PREFIX}/dbus-1/syst
# This can then also be used for packaging with cpack.
set(INSTALL_TARGETS_DEFAULT_ARGS RUNTIME DESTINATION ${BIN_INSTALL_DIR}
LIBRARY DESTINATION ${LIB_INSTALL_DIR}
- ARCHIVE DESTINATION ${LIB_INSTALL_DIR})
+ ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
+ INCLUDES DESTINATION ${INCLUDE_INSTALL_DIR})
I recommend updating the requirement as below:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 7255a11..30b5fc3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,10 +1,10 @@
-set(reqd_cmake 2.8.10.20130411)
+set(reqd_cmake 2.8.11.20130815)
if (CMAKE_VERSION VERSION_LESS reqd_cmake)
message(FATAL_ERROR
- KDE Frameworks requires CMake 2.8.11 RC 3 or later.
+ KDE Frameworks requires CMake 2.8.12 RC 1 or later.
- http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46346
+ http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/47443
I recommend not updating the requirement again until the final 2.8.12
release is made, unless there's a sufficiently good reason to do so.
Thanks,
Steve.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
Hi, On Tuesday 20 August 2013, Stephen Kelly wrote: Hello, CMake 2.8.12 RC 1 was released a few hours ago: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/47443 Updating to that will allow us to get on the home straight with regard to our buildsystem files. please wait with updating the required version until 2.8.12 final is out. There have been complaints about requiring unreleased versions of cmake, e.g. by Aaron. I actually don't have to say that, since it should be obvious to everybody here, I also object to requiring non-final versions of cmake, it just makes life harder for everybody trying to contribute. Except the very very early phase before cmake 2.4.3 or so, we never did that, and I don't think we need to start with that now. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Updating CMake requirement to 2.8.12 RC 1
Alexander Neundorf wrote: Hi, On Tuesday 20 August 2013, Stephen Kelly wrote: Hello, CMake 2.8.12 RC 1 was released a few hours ago: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/47443 Updating to that will allow us to get on the home straight with regard to our buildsystem files. please wait with updating the required version until 2.8.12 final is out. There have been complaints about requiring unreleased versions of cmake, e.g. by Aaron. The objections from Aaron were based partly on misunderstanding. http://thread.gmane.org/gmane.comp.kde.devel.frameworks/2339/focus=2357 For example, he complained about a 'dated snapshot', which I fixed in kdelibs.git with commit f1e6b8e67fe5071 (Add a better error message about the required CMake version., 2013-04-30). https://projects.kde.org/projects/kde/kdelibs/repository/revisions/f1e6b8e67fe5071a19e9ad5b8ed8ee93fa26fc4c/diff/CMakeLists.txt Additionally, I my recommendation is not to bump the required version with each release candidate made available, only this first one, and then the final. I also stand by the utility of bumping the requirement for the purpose of finding bugs. Otherwise 2.8.12 might be entirely unsuitable for frameworks. To repeat myself, actual bugs were found in 2.8.11 release candidates by using it for frameworks. So, the email from Alex does not change my recommendation at all. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
