Travis: Test build against system libs (& Qt4)

[luke-jr]

Also removes now-unnecessary bc dependency from other builds.

[laanwj]

Concept ACK on testing with qt4, but I'm not entirely happy about adding yet another build for this, Travis is slow enough these days.

[jonasschnelli]

Concept ACK.
Agree with @LaAnW but IMO another build is more valuable then a speedy CI.

[laanwj]

@jonasschnelli I wonder if there's a compromise, if we can combine the qt4 build with one of the existing builds

[jonasschnelli]

We only have one linux "full" Qt5 build "32bit + dash". The other linux QT5 build does not build the wallet. Maybe it would be worth to change one of the windows builds (Win32) to build with Qt4? On the other hand, Qt4 mostly makes sense on Linux, but even though, a Win32 Qt4 build should at least detect most Qt4 incompatibilities.

[laanwj]

Yeah. That may work.
Anyhow this is up to @theuni. Another option would be to combine this build with something else that we wanted to test already, so that it's not just added for qt4.

[luke-jr]

@theuni Can't seem to get this to build with Qt - any ideas? Shouldn't --with-qt=qt4 configure fail if it has a problem? :/

[luke-jr]

@laanwj Oh, an idea if Travis time is a concern: make this build use only system libraries (no depends). That's probably better test coverage anyway...

[laanwj]

@laanwj Oh, an idea if Travis time is a concern: make this build use only system libraries (no depends). That's probably better test coverage anyway...

Not a bad idea because of the extra test coverage with old libraries, but I don't think that will save much time as the depends are supposed to be built once and cached anyway.

[maflcko]

supposed to be built once and cached anyway.

Does travis cache between builds, I don't think so?

[laanwj]

No, not between builds, I think. In most cases this would make no sense as they have different flags or even a different platform.

[theuni]

Right. To clarify, depends are cached and re-used for subsequent builds of the same config. Each config is an island though.

Personally, I don't think this is worth adding another build for. If anything, I'd rather do as @laanwj said and combine it with another.

[laanwj]

Travis PR test is quite slow lately. I'd certainly prefer not to add another config.

Testing more obscure platforms and library versions (like Qt4) may be better suited for something like a nightly extended build (e.g. #7148)

[luke-jr]

Once #7339 is merged, I suggest this can be extended to test --without-libevent as well.

[laanwj]

Closing, this is part of #7148 now

[laanwj]

Needs rebase.

[jtimon]

Concept ACK

[luke-jr]

Rebased, sorry for the delay

[TheBlueMatt]

Concept ACK. Only concern is are we willing to add more jobs to travis? Can we pay them to make things go faster?

[maflcko]

@TheBlueMatt According to apache, it is possible to increase the number of concurrent builds. (https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci)

Though, I am slightly worried that this makes it harder for developers to fork the project and enable travis on their fork. After switching to the paid infrastructure, we might have faster machines or even extended timeouts for the build times. By forking the project, the new limits no longer apply and builds might time out or fail, which is a nuisance for new contributors.

[maflcko]

Is this still WIP or ready for review?

[maflcko]

No need for the bc package. Also, the configure option is called --with-gui=qt4.

[luke-jr]

Why is bc not needed here? Other builds need it...?

[maflcko]

I can't figure out why the "GNU bc arbitrary precision calculator language" is required. It is likely an artifact of the days where the functional tests were written in bash.

[maflcko]

bitcoin/qa/rpc-tests/util.sh

Line 38 in 2191eac

if (( $( echo "$1 == $2" | bc ) == 0 ))

[luke-jr]

Fixed issues, rebased, and removed bc from the other builds too.

[luke-jr]

There, tests pass now, and it tests against more system dependencies as well.

[maflcko]

utACK 6d2aac8