Re: [cmake-developers] 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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
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
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
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. 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. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On 10/23/2014 10:34 PM, Ben Boeckel wrote:
implies the build isn't getting the include directories plumbed through
properly.
I reproduced it locally far enough to find that kcoreaddons is not
installing headers like include/KF5/KCoreAddons/kpluginfactory.h
when built with 3.1 but is with 3.0. I narrowed it down to a test
case using just ECM:
---
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(Minimal NONE)
file(WRITE ${CMAKE_CURRENT_SOURCE_DIR}/header.h header)
find_package(ECM 1.3.0 REQUIRED NO_MODULE)
set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH})
include(ECMGenerateHeaders)
ecm_generate_headers(headers
HEADER_NAMES header
REQUIRED_HEADERS headers
)
message(WARNING headers=[${headers}])
ecm_generate_headers(headers
HEADER_NAMES header
REQUIRED_HEADERS headers
)
message(FATAL_ERROR headers=[${headers}])
---
With 3.0 we see the list of headers accumulate. With 3.1 just the
first one works and the rest do not.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On 10/24/2014 09:50 AM, Brad King wrote: With 3.0 we see the list of headers accumulate. With 3.1 just the first one works and the rest do not. I bisected it down to: commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 Author: Ben Boeckel ben.boec...@kitware.com Date: Wed Mar 12 14:01:45 2014 -0400 cmDefinitions: Don't store parent lookups When looking up scopes, it is faster to not store the lookup locally to keep the maps smaller and avoid extra allocations and rebalancing. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On 10/24/2014 10:02 AM, Brad King wrote:
I bisected it down to:
commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49
Author: Ben Boeckel ben.boec...@kitware.com
Date: Wed Mar 12 14:01:45 2014 -0400
cmDefinitions: Don't store parent lookups
When looking up scopes, it is faster to not store the lookup locally to
keep the maps smaller and avoid extra allocations and rebalancing.
Here is a minimal standalone example:
$ cat regression.cmake
function(func var_name)
list(APPEND ${var_name} value)
set(${var_name} ${${var_name}} PARENT_SCOPE)
set(${var_name} ${${var_name}} PARENT_SCOPE)
endfunction()
func(var)
message(STATUS var=[${var}])
func(var)
message(STATUS var=[${var}])
$ cmake-3.0 -P regression.cmake
-- var=[value]
-- var=[value;value]
$ cmake-3.1 -P regression.cmake
-- var=[value]
-- var=[value]
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Friday 24 October 2014 10:02:31 Brad King wrote:
On 10/24/2014 09:50 AM, Brad King wrote:
With 3.0 we see the list of headers accumulate. With 3.1 just the
first one works and the rest do not.
I bisected it down to:
commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49
Author: Ben Boeckel ben.boec...@kitware.com
Date: Wed Mar 12 14:01:45 2014 -0400
cmDefinitions: Don't store parent lookups
When looking up scopes, it is faster to not store the lookup locally to
keep the maps smaller and avoid extra allocations and rebalancing.
-Brad
Which matches my trimmed-down testcase:
-
cmake_minimum_required(VERSION 3.0)
project(Minimal NONE)
function(test_append varname entry)
list(APPEND ${varname} ${entry})
set(${varname} ${${varname}} PARENT_SCOPE)
set(${varname} ${${varname}} PARENT_SCOPE)
endfunction()
test_append(blah entry1)
message(STATUS blah=${blah})
test_append(blah entry2)
message(FATAL_ERROR blah=${blah})
-
It's that double-setting of the variable in the parent scope that seems to be
the killer.
Alex
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Friday 24 October 2014 10:20:42 Brad King wrote:
On 10/24/2014 10:02 AM, Brad King wrote:
I bisected it down to:
commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49
Author: Ben Boeckel ben.boec...@kitware.com
Date: Wed Mar 12 14:01:45 2014 -0400
cmDefinitions: Don't store parent lookups
When looking up scopes, it is faster to not store the lookup locally
to
keep the maps smaller and avoid extra allocations and rebalancing.
Here is a minimal standalone example:
$ cat regression.cmake
function(func var_name)
list(APPEND ${var_name} value)
set(${var_name} ${${var_name}} PARENT_SCOPE)
set(${var_name} ${${var_name}} PARENT_SCOPE)
endfunction()
func(var)
message(STATUS var=[${var}])
func(var)
message(STATUS var=[${var}])
$ cmake-3.0 -P regression.cmake
-- var=[value]
-- var=[value;value]
$ cmake-3.1 -P regression.cmake
-- var=[value]
-- var=[value]
-Brad
Even simpler:
---
cmake_minimum_required(VERSION 3.0)
project(Minimal NONE)
function(test_set)
set(blah value2)
message(STATUS before PARENT_SCOPE blah=${blah})
set(blah ${blah} PARENT_SCOPE)
message(STATUS after PARENT_SCOPE blah=${blah})
endfunction()
set(blah value1)
test_set()
message(FATAL_ERROR in parent scope, blah=${blah})
--
With CMake master:
-- before PARENT_SCOPE blah=value2
-- after PARENT_SCOPE blah=value1
CMake Error at CMakeLists.txt:13 (message):
in parent scope, blah=value2
With CMake 3.0.2:
-- before PARENT_SCOPE blah=value2
-- after PARENT_SCOPE blah=value2
CMake Error at CMakeLists.txt:13 (message):
in parent scope, blah=value2
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Fri, Oct 24, 2014 at 15:24:57 +0100, Alex Merry wrote:
On Friday 24 October 2014 10:20:42 Brad King wrote:
On 10/24/2014 10:02 AM, Brad King wrote:
commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49
Author: Ben Boeckel ben.boec...@kitware.com
Date: Wed Mar 12 14:01:45 2014 -0400
cmDefinitions: Don't store parent lookups
When looking up scopes, it is faster to not store the lookup locally
to
keep the maps smaller and avoid extra allocations and rebalancing.
So the problem was that when redoing the pull logic for PARENT_SCOPE,
it was unconditional when it should be skipped if the variable is
already local.
Pushed to stage as:
variable-pull-failure
---
cmake_minimum_required(VERSION 3.0)
project(Minimal NONE)
function(test_set)
set(blah value2)
message(STATUS before PARENT_SCOPE blah=${blah})
set(blah ${blah} PARENT_SCOPE)
message(STATUS after PARENT_SCOPE blah=${blah})
endfunction()
set(blah value1)
test_set()
message(FATAL_ERROR in parent scope, blah=${blah})
--
Now added as a test in CMake (with minor changes).
Thanks,
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Fri, Oct 24, 2014 at 10:54:17 -0400, Ben Boeckel wrote: On Fri, Oct 24, 2014 at 15:24:57 +0100, Alex Merry wrote: On Friday 24 October 2014 10:20:42 Brad King wrote: On 10/24/2014 10:02 AM, Brad King wrote: commit 5abfde6cb8a1ae0b2825797eab6c2e9842eb7c49 Author: Ben Boeckel ben.boec...@kitware.com Date: Wed Mar 12 14:01:45 2014 -0400 cmDefinitions: Don't store parent lookups When looking up scopes, it is faster to not store the lookup locally to keep the maps smaller and avoid extra allocations and rebalancing. So the problem was that when redoing the pull logic for PARENT_SCOPE, it was unconditional when it should be skipped if the variable is already local. So after discussion with Brad, this commit breaks other subtle behaviors as well, so the plan is to just revert it instead and defer its optimizations until after 3.1 once proper tests are in place (more under development now). --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Severe behavioural change regressions in release branch
On Fri, Oct 24, 2014 at 11:36:40 -0400, Ben Boeckel wrote: So after discussion with Brad, this commit breaks other subtle behaviors as well, so the plan is to just revert it instead and defer its optimizations until after 3.1 once proper tests are in place (more under development now). There are two branches on stage now (the previously mentioned branch has been reverted): - parent-scope-tests Based on v3.0.0~ to test that it worked on the release. This includes the more complex testing of PARENT_SCOPE's behaviors. - revert-definition-map-lookup Based on the bad commit, this reverts it with a description of what it is happening and then merges in parent-scope-tests to ensure that it works there. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] 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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
