Re: Severe behavioural change regressions in release branch
On Sat, Oct 25, 2014 at 7:14 PM, Stephen Kelly steve...@gmail.com wrote: Ben Cooksley wrote: On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com wrote: Is build.kde.org now using the release branch of cmake.git instead of the next branch? When/why did that change? This was changed around about http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html That thread is... unsettling. No participant suggested reporting the issue. Four months later bigger waves are made. Yes. KDE and CMake are the same in that both rely on people hitting problems to report them. This could have been fixed mere days after it hit master. Something for KDE to learn from I hope. If anyone is interested, help would be appreciated to get a Contracts style build up and running. In particular, pointers to documentation on how to perform such builds would be appreciated - we'll need to run make install for parts of it which doesn't seem to happen in any of the existing examples as far as I can see. Thanks, Steve. Thanks, Ben ___ Kde-buildsystem mailing list kde-buildsys...@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Tue, Oct 28, 2014 at 09:58:58 +1300, Ben Cooksley wrote:
If anyone is interested, help would be appreciated to get a Contracts
style build up and running.
In particular, pointers to documentation on how to perform such builds
would be appreciated - we'll need to run make install for parts of
it which doesn't seem to happen in any of the existing examples as far
as I can see.
Since it's a CMake build, ExternalProject should make it fairly
straightforward. A quick sketch of the non-boilerplate code I see in the
current contracts tests:
externalproject_add(kdelibs
GIT_REPOSITORY [...]
GIT_TAG[...] # The oldest supported release.
CMAKE_ARGS
[...]
INSTALL_DIR${CMAKE_CURRENT_BINARY_DIR}/install)
externalproject_add(someotherkdelib
DEPENDSkdelibs
GIT_REPOSITORY [...]
GIT_TAG[...] # The oldest supported release.
CMAKE_ARGS
# Might not be necessary.
-DCMAKE_MODULE_PATH={$CMAKE_CURRENT_BINARY_DIR}/install/lib/cmake
[...]
INSTALL_DIR${CMAKE_CURRENT_BINARY_DIR}/install)
The rationale for using the oldest supported release is so that we make
sure whatever was written *then* still works today.
--Ben
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Severe behavioural change regressions in release branch
On Sat, Oct 25, 2014 at 08:50:12 +1300, Ben Cooksley wrote: On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com wrote: Is build.kde.org now using the release branch of cmake.git instead of the next branch? When/why did that change? This was changed around about http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html The motivation behind the change was to get the CI system to have the same setup as developers I think, and to avoid regressions in 3.1 which had been causing some build problems at the time. Those same regressions are the ones causing us issues now. Interestingly, the commit which was identified as causing the issue occurred back in March, yet this thread was in June. So perhaps there may be other commits interacting here (or that was the time when the commit previously identified was merged into the next branch). Earlier this year, I was working on lots of performance metrics of CMake and this was part of it. There ended up being more than a dozen branches resulting from that work (some of them still unmerged). Doing some digging shows that this is where the commit finally hit master: commit bd20dd6b8a925a421167602027fff9b904fd0822 Merge: b041fc1 e17a69b Author: Brad King brad.k...@kitware.com Date: Thu Jun 12 11:28:44 2014 -0400 so June looks right. --Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Severe behavioural change regressions in release branch
Earlier this year, I was working on lots of performance metrics of CMake and this was part of it. There ended up being more than a dozen branches resulting from that work (some of them still unmerged). Doing some digging shows that this is where the commit finally hit master: commit bd20dd6b8a925a421167602027fff9b904fd0822 Merge: b041fc1 e17a69b Author: Brad King brad.k...@kitware.com Date: Thu Jun 12 11:28:44 2014 -0400 Yep, I can verify that I had to use on OSX/CI the version from June 3rd for quite a while, since that was the only one which would give me the desired builds. Greets, Marko ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Severe behavioural change regressions in release branch
Hi guys, what's the status of this? As far as i can see it's still unresolved since kcoreaddons is installing much fewer headers than it used to http://build.kde.org/job/kcoreaddons_master_qt5/153/console vs http://build.kde.org/job/kcoreaddons_master_qt5/152/console Do you think it's a valid case to autotest? Cheers, Albert El Divendres, 24 d'octubre de 2014, a les 19:23:42, Ben Boeckel va escriure: On Sat, Oct 25, 2014 at 08:50:12 +1300, Ben Cooksley wrote: On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com wrote: Is build.kde.org now using the release branch of cmake.git instead of the next branch? When/why did that change? This was changed around about http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html The motivation behind the change was to get the CI system to have the same setup as developers I think, and to avoid regressions in 3.1 which had been causing some build problems at the time. Those same regressions are the ones causing us issues now. Interestingly, the commit which was identified as causing the issue occurred back in March, yet this thread was in June. So perhaps there may be other commits interacting here (or that was the time when the commit previously identified was merged into the next branch). Earlier this year, I was working on lots of performance metrics of CMake and this was part of it. There ended up being more than a dozen branches resulting from that work (some of them still unmerged). Doing some digging shows that this is where the commit finally hit master: commit bd20dd6b8a925a421167602027fff9b904fd0822 Merge: b041fc1 e17a69b Author: Brad King brad.k...@kitware.com Date: Thu Jun 12 11:28:44 2014 -0400 so June looks right. --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: Severe behavioural change regressions in release branch
On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com wrote: Ben Cooksley wrote: Hi all, It would appear that CMake 3.0 to 3.1 introduces a colossal change in behaviour. This change totally breaks all KDE projects which use Extra-CMake-Modules, as necessary headers are no longer installed. This has become an issue following http://build.kde.org/job/cmake/160/ which has led to a significant number of our projects failing to build from source as can be seen here - http://build.kde.org/view/Frameworks/ Hi Steve, Is build.kde.org now using the release branch of cmake.git instead of the next branch? When/why did that change? This was changed around about http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html The motivation behind the change was to get the CI system to have the same setup as developers I think, and to avoid regressions in 3.1 which had been causing some build problems at the time. Those same regressions are the ones causing us issues now. Interestingly, the commit which was identified as causing the issue occurred back in March, yet this thread was in June. So perhaps there may be other commits interacting here (or that was the time when the commit previously identified was merged into the next branch). Thanks, Steve. Thanks, Ben ___ Kde-buildsystem mailing list kde-buildsys...@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Severe behavioural change regressions in release branch
Hi all, It would appear that CMake 3.0 to 3.1 introduces a colossal change in behaviour. This change totally breaks all KDE projects which use Extra-CMake-Modules, as necessary headers are no longer installed. This has become an issue following http://build.kde.org/job/cmake/160/ which has led to a significant number of our projects failing to build from source as can be seen here - http://build.kde.org/view/Frameworks/ Someone needs to investigate this before CMake 3.1.0 goes out the door and fix it. I've no idea what the policy is in the CMake world, but in the KDE world this sort of compatibility breakage would be a release blocker. Regards, Ben Cooksley KDE Sysadmin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Severe behavioural change regressions in release branch
On Fri, Oct 24, 2014 at 10:05 AM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It would appear that CMake 3.0 to 3.1 introduces a colossal change in behaviour. This change totally breaks all KDE projects which use Extra-CMake-Modules, as necessary headers are no longer installed. This has become an issue following http://build.kde.org/job/cmake/160/ which has led to a significant number of our projects failing to build from source as can be seen here - http://build.kde.org/view/Frameworks/ Someone needs to investigate this before CMake 3.1.0 goes out the door and fix it. I've no idea what the policy is in the CMake world, but in the KDE world this sort of compatibility breakage would be a release blocker. And it would seem that the CMake developers prefer to live in their own closed off little bubble. My post was automatically rejected. Someone who is subscribed there will have to take this up with them. I'm extremely displeased. If they release CMake 3.1.0 with this regression, we should consider forking CMake as their developers can't be trusted to ensure our code remains buildable. Regards, Ben Cooksley KDE Sysadmin Regards, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Severe behavioural change regressions in release branch
On Fri, Oct 24, 2014 at 10:41 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On 10/23/2014 5:11 PM, Ben Cooksley wrote: And it would seem that the CMake developers prefer to live in their own closed off little bubble. Hi Bill, Sorry about that. We just want to avoid spam. I have forwarded your message to the cmake-developers mailing list. Thanks for the report. Okay, sounds reasonable enough. Thanks for taking care of that. -Bill Thanks, Ben ___ Kde-buildsystem mailing list kde-buildsys...@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Severe behavioural change regressions in release branch
On Fri, Oct 24, 2014 at 10:11 AM, Ben Cooksley bcooks...@kde.org wrote: On Fri, Oct 24, 2014 at 10:05 AM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It would appear that CMake 3.0 to 3.1 introduces a colossal change in behaviour. This change totally breaks all KDE projects which use Extra-CMake-Modules, as necessary headers are no longer installed. This has become an issue following http://build.kde.org/job/cmake/160/ which has led to a significant number of our projects failing to build from source as can be seen here - http://build.kde.org/view/Frameworks/ Someone needs to investigate this before CMake 3.1.0 goes out the door and fix it. I've no idea what the policy is in the CMake world, but in the KDE world this sort of compatibility breakage would be a release blocker. And it would seem that the CMake developers prefer to live in their own closed off little bubble. My post was automatically rejected. Someone who is subscribed there will have to take this up with them. I'm extremely displeased. If they release CMake 3.1.0 with this regression, we should consider forking CMake as their developers can't be trusted to ensure our code remains buildable. Sorry for the above all, got a bit caught up in the heat of the moment. That shouldn't have come out in the way it did. Hopefully we have a solution on the way now... Regards, Ben Cooksley KDE Sysadmin Regards, Ben Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
