Re: [cmake-developers] [Patch 5/5] Improved WIX support
On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote: Here it is. The patch only seems to allow patching Features generated for components but not Features generated for component groups. Is that intentional or an oversight? I think we should allow patching for both. Nils -- 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] [CMake] Setup/tear down steps for CTest
On Thu, Sep 8, 2016 at 5:52 PM, Brad King wrote: > On 09/08/2016 10:15 AM, Craig Scott wrote: >> the current behaviour of DEPENDS. At the moment, if test B depends >> on test A, test B still executes if test A fails. >> It is unexpected because I'd initially have thought of DEPENDS as >> meaning I can't run test B if test A fails, after all, B depends >> on A which I'd interpret to mean if A fails, then something B requires >> isn't working. Conversely, this is also useful because until now, >> DEPENDS was the only way to get cleanup functionality to run after >> other tests, and if those other tests fail, we still want the >> cleanup to occur. > > At one time we only had serial testing so the order of tests was > fully controllable and based on the order of addition. There were > never any conditions for whether a test would run based on results > of other tests. Then when parallel testing was added we need a > way to restore *order* dependencies, so DEPENDS was added just > for that. Maybe a better name would have been RUN_AFTER. > >> adding a DEPENDS_ON_SUCCESS test property or something similar >> which would implement the perhaps more intuitive behaviour of not >> running dependent tests when a dependee fails. If that was done, >> then implementing the "don't run fixture tests if any fixture >> setup fails" logic would be trivial. > > The semantics of this will have to be carefully though out, in > particular with respect to enabling test dependencies. Right now > ctest arguments like -E can exclude tests. What if those are > dependencies of included tests? > > I think if we introduce the notion of tests requiring other tests > then a new model of test selection and enablement needs to be > designed. Some kind of test DAG could be defined with various > roots and subgraphs being selectable an causing all reachable > tests to be included. This could be expanded even further. If "tests requiring other tests" is generalized to "tests requiring X", wouldn't this allow incremental testing? Say you change one file in your project. You rebuild only the parts of the project that are affected by this change. Then you rerun only the tests that are affected by the change. This really has to be carefully thought out. Cheers, Daniel -- 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
[cmake-developers] [patch] FreeBSD build fix
With FreeBSD 11, I was getting a link failure due to missing kvm symbols in Utilities/cmlibuv. The fix is a trivial addition. It's added unconditionally; I checked for its presence in FreeBSD 11, 10 and 9. Branch: freebsd-kvm-link Merged into stage for testing. Regards, Roger -- 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
[cmake-developers] [patch] BZip2 imported targets
Adds BZip2::BZip2 imported target and documentation, along with unit test which may be enabled with the CMake_TEST_FindBZip2 option. Derived from the existing code in FindZLib. Branch: bzip2-imported-targets Merged into stage for testing. Regards, Roger -- 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] CMake version to build CMake
On 09/08/2016 02:17 PM, Stephen Kelly wrote: > Are there dashboard machines which need to be updated first? Oops, right. I see a bunch that are still on 2.8.12. There are only a few older than that (2.8.7, 2.8.9, 2.8.11). I'll try to get those updated soon and report back. Then we can move to 2.8.12 for now. Thanks, -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] CMake version to build CMake
Brad King wrote: > On 09/07/2016 06:44 PM, Stephen Kelly wrote: >> ALIAS targets were introduced in CMake 2.8.12 (released August 2013). >> >> What do you think of updating the requirement to that or higher? > > Fine with me. It really only matters on platforms where one cannot use > the bootstrap script. Let's go to 3.0 so we have the option to use the > bracket argument syntax. Are there dashboard machines which need to be updated first? 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] [CMake] Setup/tear down steps for CTest
On 09/08/2016 10:15 AM, Craig Scott wrote: > the current behaviour of DEPENDS. At the moment, if test B depends > on test A, test B still executes if test A fails. > It is unexpected because I'd initially have thought of DEPENDS as > meaning I can't run test B if test A fails, after all, B depends > on A which I'd interpret to mean if A fails, then something B requires > isn't working. Conversely, this is also useful because until now, > DEPENDS was the only way to get cleanup functionality to run after > other tests, and if those other tests fail, we still want the > cleanup to occur. At one time we only had serial testing so the order of tests was fully controllable and based on the order of addition. There were never any conditions for whether a test would run based on results of other tests. Then when parallel testing was added we need a way to restore *order* dependencies, so DEPENDS was added just for that. Maybe a better name would have been RUN_AFTER. > adding a DEPENDS_ON_SUCCESS test property or something similar > which would implement the perhaps more intuitive behaviour of not > running dependent tests when a dependee fails. If that was done, > then implementing the "don't run fixture tests if any fixture > setup fails" logic would be trivial. The semantics of this will have to be carefully though out, in particular with respect to enabling test dependencies. Right now ctest arguments like -E can exclude tests. What if those are dependencies of included tests? I think if we introduce the notion of tests requiring other tests then a new model of test selection and enablement needs to be designed. Some kind of test DAG could be defined with various roots and subgraphs being selectable an causing all reachable tests to be included. -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] [CMake] Setup/tear down steps for CTest
I should also point out that another reason for not implementing the "skipping tests if the setup fails logic" relates to the current behaviour of DEPENDS. At the moment, if test B depends on test A, test B still executes if test A fails. This is both useful and unexpected at the same time. It is unexpected because I'd initially have thought of DEPENDS as meaning I can't run test B if test A fails, after all, B depends on A which I'd interpret to mean if A fails, then something B requires isn't working. Conversely, this is also useful because until now, DEPENDS was the only way to get cleanup functionality to run after other tests, and if those other tests fail, we still want the cleanup to occur. Current behaviour of DEPENDS can't change because there would be too much out there in the wild relying on the existing behaviour. I'm wondering if there's merit in adding a DEPENDS_ON_SUCCESS test property or something similar which would implement the perhaps more intuitive behaviour of not running dependent tests when a dependee fails. If that was done, then implementing the "don't run fixture tests if any fixture setup fails" logic would be trivial. On Thu, Sep 8, 2016 at 6:08 PM, Craig Scott wrote: > Merge request implementing this feature is now up for review here: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/88 > > I ended up going with FIXTURE_... test property names rather than > GROUP_... since it seemed more specific. I have not implemented the logic > for skipping regular tests if any of a fixture's setup tests fail as that > would require more change than I wanted to bite off for this initial > implementation. If it is really required, I guess it could be done, but my > primary concern first is not to introduce new bugs. ;) > > > > On Thu, Sep 1, 2016 at 9:17 AM, Craig Scott > wrote: > >> Actually, we can't really re-use the RESOURCE_LOCK for the proposed >> RESOURCE_SETUP and RESOURCE_CLEANUP functionality since that would force >> all the tests using that resource to be serialised. So yes, a separate >> GROUP or something similar would seem to be needed. Let me amend my earlier >> proposal (which is an evolution of Ben's) to something like this: >> >> >> add_test(NAME setup-foo ...) >> set_tests_properties(setup-foo PROPERTIES GROUP_SETUP foo) >> >> add_test(NAME cleanup-foo ...) >> set_tests_properties(cleanup-foo PROPERTIES GROUP_CLEANUP foo) >> >> add_test(NAME use-foo ...) >> set_tests_properties(use-foo PROPERTIES GROUP foo) >> >> >> The logic would be as follows: >> >>- Any test cases with a GROUP_SETUP property for a group will be run >>before any test cases with GROUP or GROUP_CLEANUP for that same group. The >>order of these setup test cases can be controlled with the existing >> DEPENDS >>test property. >>- If any of the group's setup test cases fail, all other test cases >>for that group will be skipped. All cleanup test cases for the group >>probably should still be run though (it could be hard to try to work out >>which cleanup tests should run, so maybe conservatively just run all of >>them). >>- If all setup test cases passed, then run all test cases for that >>group. Regardless of the success or failure of these test cases, once they >>are all completed, run all the cleanup test cases associated with the >> group. >>- Ordering of cleanup test cases can again be controlled with the >>existing DEPENDS test property. >> >> What the above buys us is that CTest then knows definitively that if it >> is asked to run a test case from a particular group, it must also run the >> setup and cleanup test cases associated with that group, regardless of >> whether those setup/cleanup test cases are in the set of test cases CTest >> was originally asked to run. At the moment, CTest could theoretically do >> that for the setup steps based on DEPENDS functionality, but not the >> cleanup. The above proposal is very clear about the nature of the >> dependency and gives the symmetry of both setup and cleanup behaviour. >> >> I'm not tied to the terminology of "GROUP" for tying a set of test cases >> to their setup/cleanup tasks, so I'm happy to consider alternatives. I'm >> also wondering whether simply GROUP for a test property is too generic for >> the test cases that require the setup/cleanup (as opposed to the test cases >> that ARE the setup/cleanup). >> >> >> On Thu, Sep 1, 2016 at 10:50 AM, Craig Scott >> wrote: >> >>> In my original thinking, I was of the view that if a setup/cleanup step >>> needed to be executed for each test rather than for the overall test run as >>> a whole, then perhaps the test itself should handle that rather than CMake. >>> The existing RESOURCE_LOCK functionality could then be used to prevent >>> multiple tests from running concurrently if they would interfere with each >>> other. Existing test frameworks like GoogleTest and Boost Test already have >>> good support for test fixtures which ma
Re: [cmake-developers] CMake version to build CMake
On 09/07/2016 06:44 PM, Stephen Kelly wrote: > ALIAS targets were introduced in CMake 2.8.12 (released August 2013). > > What do you think of updating the requirement to that or higher? Fine with me. It really only matters on platforms where one cannot use the bootstrap script. Let's go to 3.0 so we have the option to use the bracket argument syntax. -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] [CMake] Setup/tear down steps for CTest
Merge request implementing this feature is now up for review here: https://gitlab.kitware.com/cmake/cmake/merge_requests/88 I ended up going with FIXTURE_... test property names rather than GROUP_... since it seemed more specific. I have not implemented the logic for skipping regular tests if any of a fixture's setup tests fail as that would require more change than I wanted to bite off for this initial implementation. If it is really required, I guess it could be done, but my primary concern first is not to introduce new bugs. ;) On Thu, Sep 1, 2016 at 9:17 AM, Craig Scott wrote: > Actually, we can't really re-use the RESOURCE_LOCK for the proposed > RESOURCE_SETUP and RESOURCE_CLEANUP functionality since that would force > all the tests using that resource to be serialised. So yes, a separate > GROUP or something similar would seem to be needed. Let me amend my earlier > proposal (which is an evolution of Ben's) to something like this: > > > add_test(NAME setup-foo ...) > set_tests_properties(setup-foo PROPERTIES GROUP_SETUP foo) > > add_test(NAME cleanup-foo ...) > set_tests_properties(cleanup-foo PROPERTIES GROUP_CLEANUP foo) > > add_test(NAME use-foo ...) > set_tests_properties(use-foo PROPERTIES GROUP foo) > > > The logic would be as follows: > >- Any test cases with a GROUP_SETUP property for a group will be run >before any test cases with GROUP or GROUP_CLEANUP for that same group. The >order of these setup test cases can be controlled with the existing DEPENDS >test property. >- If any of the group's setup test cases fail, all other test cases >for that group will be skipped. All cleanup test cases for the group >probably should still be run though (it could be hard to try to work out >which cleanup tests should run, so maybe conservatively just run all of >them). >- If all setup test cases passed, then run all test cases for that >group. Regardless of the success or failure of these test cases, once they >are all completed, run all the cleanup test cases associated with the > group. >- Ordering of cleanup test cases can again be controlled with the >existing DEPENDS test property. > > What the above buys us is that CTest then knows definitively that if it is > asked to run a test case from a particular group, it must also run the > setup and cleanup test cases associated with that group, regardless of > whether those setup/cleanup test cases are in the set of test cases CTest > was originally asked to run. At the moment, CTest could theoretically do > that for the setup steps based on DEPENDS functionality, but not the > cleanup. The above proposal is very clear about the nature of the > dependency and gives the symmetry of both setup and cleanup behaviour. > > I'm not tied to the terminology of "GROUP" for tying a set of test cases > to their setup/cleanup tasks, so I'm happy to consider alternatives. I'm > also wondering whether simply GROUP for a test property is too generic for > the test cases that require the setup/cleanup (as opposed to the test cases > that ARE the setup/cleanup). > > > On Thu, Sep 1, 2016 at 10:50 AM, Craig Scott > wrote: > >> In my original thinking, I was of the view that if a setup/cleanup step >> needed to be executed for each test rather than for the overall test run as >> a whole, then perhaps the test itself should handle that rather than CMake. >> The existing RESOURCE_LOCK functionality could then be used to prevent >> multiple tests from running concurrently if they would interfere with each >> other. Existing test frameworks like GoogleTest and Boost Test already have >> good support for test fixtures which make doing this per-test setup/cleanup >> easy. The problem I want to solve is where a group of tests share a common >> (set of) setup/cleanup steps and CMake knows to run them when asked to run >> any test cases that require them. The specific problem motivating this work >> was running ctest --rerun-failed, where we need CMake to add in any >> setup/cleanup steps required by any of the tests that will be rerun. With >> that in mind, see further comments interspersed below. >> >> >> On Fri, Aug 26, 2016 at 12:08 AM, Ben Boeckel >> wrote: >> >>> On Tue, Aug 23, 2016 at 08:00:09 +0200, Rolf Eike Beer wrote: >>> > Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott: >>> > > So how would you want the feature to work? I'd suggest an initial >>> set of >>> > > requirements something like the following: >>> > > >>> > >- Need to support the ability to define multiple setup and/or >>> tear down >>> > >tasks. >>> > >- It should be possible to specify dependencies between setup >>> tasks and >>> > >between tear down tasks. >>> > >- Individual tests need to be able to indicate which setup and/or >>> tear >>> > >down tasks they require, similar to the way DEPENDS is used to >>> specify >>> > >dependencies between test cases. >>> > >- When using ctest --rerun-failed,
Re: [cmake-developers] [Patch 5/5] Improved WIX support
On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote: Yes I tried, didn't work somehow. Never mind, the current approach works. It should have worked. I've added a new working test case to my suite: https://github.com/ngladitz/cmake-wix-testsuite/tree/master/feature_ref_in_product I'll look into integrating your patch for consistency nonetheless but it should not really have been required for your use case. Nils -- 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
