This would be helpful for upgrading Qt (#12971) and protobuf (#13513)
27 | @@ -28,11 +28,11 @@ env: 28 | # ARM 29 | - HOST=arm-linux-gnueabihf PACKAGES="g++-arm-linux-gnueabihf" DEP_OPTS="NO_QT=1" GOAL="install" BITCOIN_CONFIG="--enable-glibc-back-compat --enable-reduce-exports" 30 | # Win32 31 | - - HOST=i686-w64-mingw32 DPKG_ADD_ARCH="i386" DEP_OPTS="NO_QT=1" PACKAGES="python3 nsis g++-mingw-w64-i686 wine-binfmt wine32" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-reduce-exports" 32 | + - HOST=i686-w64-mingw32 DPKG_ADD_ARCH="i386" PACKAGES="python3 nsis g++-mingw-w64-i686 wine-binfmt wine32" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-reduce-exports --disable-gui-tests" 33 | # Win64 34 | - - HOST=x86_64-w64-mingw32 DEP_OPTS="NO_QT=1" PACKAGES="python3 nsis g++-mingw-w64-x86-64 wine-binfmt wine64" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-reduce-exports" 35 | + - HOST=x86_64-w64-mingw32 PACKAGES="python3 nsis g++-mingw-w64-x86-64 wine-binfmt wine64" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-reduce-exports --disable-gui-tests"
Might as well change "install" to "deploy", so we get the setup.exe as well?
Sure
Would be nicer if travis natively supported multi-job-multi-stage builds, but yeah, maybe this hack is required.
<!--e57a25ab6845829454e8d69fc972939a-->Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Update: Enable qt for arm
71 | - - DOCKER_EXEC ./configure --cache-file=../config.cache $BITCOIN_CONFIG_ALL $BITCOIN_CONFIG || ( cat config.log && false) 72 | - - DOCKER_EXEC make $MAKEJOBS $GOAL || ( echo "Build failure. Verbose build follows." && DOCKER_EXEC make $GOAL V=1 ; false ) 73 | - - if [ "$RUN_TESTS" = "true" ]; then DOCKER_EXEC LD_LIBRARY_PATH=$TRAVIS_BUILD_DIR/depends/$HOST/lib make $MAKEJOBS check VERBOSE=1; fi 74 | - - if [ "$TRAVIS_EVENT_TYPE" = "cron" ]; then extended="--extended --exclude feature_pruning,feature_dbcrash"; fi 75 | - - if [ "$RUN_TESTS" = "true" ]; then DOCKER_EXEC test/functional/test_runner.py --combinedlogslen=4000 --coverage --quiet --failfast ${extended}; fi 76 | + # Skip Bitcoin Core build if depends build take more than 20 mins.
hmm. Not sure about that. We'd have to manually reset travis on all pull requests that are affected by this.
We'd have to manually reset travis on all pull requests that are affected by this.
We can clear the cache of all PRs to solve this just like what we do after migrate tests to docker.
What I mean is that a early exit should not make travis green. Maybe add an echo "Travis early exit to cache current state" && false somewhere?
It does not make travis green. If test $SECONDS -lt 1200 has failed, travis would turn out red. But it's a good idea to add error message.
Ah thanks for the clarification. I missed that.
122 | - - if [ "$RUN_TESTS" = "true" ]; then BEGIN_FOLD unit-tests; DOCKER_EXEC LD_LIBRARY_PATH=$TRAVIS_BUILD_DIR/depends/$HOST/lib make $MAKEJOBS check VERBOSE=1; END_FOLD; fi 123 | - - if [ "$TRAVIS_EVENT_TYPE" = "cron" ]; then extended="--extended --exclude feature_pruning,feature_dbcrash"; fi 124 | - - if [ "$RUN_TESTS" = "true" ]; then BEGIN_FOLD functional-tests; DOCKER_EXEC test/functional/test_runner.py --combinedlogslen=4000 --coverage --quiet --failfast ${extended}; END_FOLD; fi 125 | + # Skip Bitcoin Core build if depends build take more than 20 mins. 126 | + - | 127 | + ( test $SECONDS -lt 1200 || ( echo Travis early exit to cache current state && false ) ) && (
This could simply be its own line in the script section.
I really like the rest of the script to be joined into a single block using the | YAML goodness, but putting this check on an individual line (- ...) would spare the ) && ( LOTSOFLINES ) awkwardness.
Thanks, I'll work on this after #13836 merged.
It's time to make Mac build work on master again.
122 | @@ -123,12 +123,11 @@ jobs: 123 | RUN_TESTS=true 124 | GOAL="install" 125 | BITCOIN_CONFIG="--enable-zmq --with-incompatible-bdb --enable-glibc-back-compat --enable-reduce-exports --with-gui=qt5 CPPFLAGS=-DDEBUG_LOCKORDER" 126 | -# x86_64 Linux, No wallet 127 | +# x86_64 Linux
Is this change intentional? I find it very handy to have a NO_WALLET build available. It has happened to me before that I changed something in a way which required the wallet in a place which does not require a wallet overall. This particular travis build caught that.
Sorry, I just noticed your description does mention that. So it is intentional. My comment still stands though, I find it beneficial to have a no-wallet build available. In a perfect world a build would build all possible combinations of build flags, in this imperfect world it can at least check the no-wallet case.
Indeed, will undo this.
This is ready for review. Thanks for #13863, I don't have to do a lot of line changes.
As this is effectively reverting a33b7c9cb545985771d074748c0e368ca2d06702, could the GOALs be changed to deploy?
@MarcoFalke Changed goals to deploy, also revert 3d69853090a9382fc31b1558a74627f61f002584 because of cf01fd6f9c1a31d16884cd1a1a686602b4b47027
128 | @@ -133,5 +129,5 @@ jobs: 129 | OSX_SDK=10.11 130 | RUN_UNIT_TESTS=false 131 | RUN_FUNCTIONAL_TESTS=false 132 | - GOAL="all deploy" 133 | + GOAL="deploy"
Why is this change needed? It doesn't seem like the mac cross build should be affected at all?
The origin motivation of 3d69853 is to compile all binaries, not only qt. But after cf01fd6 being merged, it would build all binaries even when the target is deploy. What all do has been included in what deploy do.
@MarcoFalke Do you think that this change is unnecessary?
33 | @@ -34,7 +34,7 @@ install: 34 | before_script: 35 | - set -o errexit; source .travis/test_05_before_script.sh 36 | script: 37 | - - set -o errexit; source .travis/test_06_script.sh 38 | + - if [ $SECONDS -gt 1200 ]; then set +o errexit; echo "Travis early exit to cache current state"; false; else set -o errexit; source .travis/test_06_script.sh; fi
Should this be in the before_script?
before_script does the depends build, which should be cached, so no?
I didn't know chache was discared during a premature exit. If so, then this makes sense.
Concept ACK
