Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
Am 15.11.2016 um 22:13 schrieb Leo Famulari: > Hartmut, can you push this to the recently created "staging" branch? Done. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
On Thu, Oct 13, 2016 at 10:12:01PM +0200, Ludovic Courtès wrote: > Hartmut Goebelskribis: > > > * guix/build/cmake-build-system.scm (cmake-build-system): Set > > environment variable CTEST_OUTPUT_ON_FAILURE to an non-empty value. > > It’s a good idea, but it would entail a rebuild of 1,000+ packages. Can > you save it for the next big-rebuild cycle? Hartmut, can you push this to the recently created "staging" branch? signature.asc Description: PGP signature
Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
Am 17.10.2016 um 22:14 schrieb Ludovic Courtès: > Once ‘core-updates’ is merged (hopefully in a few days), we could start > a ‘staging’ branch and put changes that require between ~300 and ~1200 > rebuilds. The idea would be to close the branch much more quickly than > core-updates (the changes should be less disruptive, with little chance > of breaking things.) This is a good idea, too. I meant some branch like "core-updates-next", as a staging branch for the next "core-updates" cycle, too. So if he core-updates are currently build, we most likely do not want to tough it. But we could already push some changes to core-updates next to get them off our todo-lists. But maybe this is just what you call "staging" branch :-) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
Hartmut Goebelskribis: > Am 13.10.2016 um 22:12 schrieb Ludovic Courtès: >> It’s a good idea, but it would entail a rebuild of 1,000+ packages. Can >> you save it for the next big-rebuild cycle? > > No problem. > > Still have to learn what "next big-rebuild cycle" means. Is there a > branch for it? Not really! Well there’s core-updates for changes that trigger a rebuild of 90% of the packages, and then occasionally topic branches (‘python-updates’, etc.) Once ‘core-updates’ is merged (hopefully in a few days), we could start a ‘staging’ branch and put changes that require between ~300 and ~1200 rebuilds. The idea would be to close the branch much more quickly than core-updates (the changes should be less disruptive, with little chance of breaking things.) Ludo’.
Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
Am 13.10.2016 um 22:12 schrieb Ludovic Courtès: > It’s a good idea, but it would entail a rebuild of 1,000+ packages. Can > you save it for the next big-rebuild cycle? No problem. Still have to learn what "next big-rebuild cycle" means. Is there a branch for it? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
Hartmut Goebelskribis: > * guix/build/cmake-build-system.scm (cmake-build-system): Set > environment variable CTEST_OUTPUT_ON_FAILURE to an non-empty value. It’s a good idea, but it would entail a rebuild of 1,000+ packages. Can you save it for the next big-rebuild cycle? Thanks, Ludo’.
[PATCH] guxi: cmake-build-system: Enable output for failing test-cases.
* guix/build/cmake-build-system.scm (cmake-build-system): Set environment variable CTEST_OUTPUT_ON_FAILURE to an non-empty value. --- guix/build/cmake-build-system.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/guix/build/cmake-build-system.scm b/guix/build/cmake-build-system.scm index f57622e..27f2b5c 100644 --- a/guix/build/cmake-build-system.scm +++ b/guix/build/cmake-build-system.scm @@ -66,6 +66,7 @@ (define* (check #:key (tests? #t) (parallel-tests? #t) (test-target "test") #:allow-other-keys) (let ((gnu-check (assoc-ref gnu:%standard-phases 'check))) +(setenv "CTEST_OUTPUT_ON_FAILURE" "1") (gnu-check #:tests? tests? #:test-target test-target #:parallel-tests? parallel-tests?))) -- 2.7.4