travis: add boringssl build #2118
Conversation
|
@davidben! Do you have a suggested tag/tag system we should use when we run test builds of curl/boringssl, or is using borginssl's master branch reasonably safe? |
.travis.yml
Outdated
| @@ -108,6 +112,20 @@ before_script: | |||
| sudo make install | |||
| ) | |||
| fi | |||
| if [ "$TRAVIS_OS_NAME" = linux -a "$BORINGSSL" ]; then | |||
| (git clone https://boringssl.googlesource.com/boringssl && | |||
| cd boringssl && | |||
There was a problem hiding this comment.
Some revisions need this:
sed -i -e '/^if (BUILD_SHARED_LIBS)/i\add_definitions(-DBORINGSSL_ENABLE_DHE_TLS)' CMakeLists.txt &&
.travis.yml
Outdated
| mkdir build && | ||
| cd build && | ||
| cmake -DCMAKE_INSTALL_PREFIX:PATH=$HOME/build-boringssl .. && | ||
| make && |
There was a problem hiding this comment.
Using cmake with this option is probably what most maintainers use:
cmake -DCMAKE_BUILD_TYPE=release …… and then you could decrease compilation time by (replace ninja by make; don't forget libdecrepit.a):
ninja crypto/libcrypto.a ssl/libssl.a decrepit/libdecrepit.aFYI, you could build everything as shared libraries, but I don't think this makes a difference for the tests.
There was a problem hiding this comment.
libdecrepit.a
What's that and what do we need that for?
There was a problem hiding this comment.
»Old« algorithms are collected in that library. For example, DSA and RC4.
There was a problem hiding this comment.
And regarding ninja: I dread to add more dependencies (problems) to the annoying travis environment. Besides, make vs ninja can't make that big difference when building from scratch in a single-core one-by-one build surely?
There was a problem hiding this comment.
Never used make here, but I think make accepts what-to-build as arguments like ninja does.
(I guess you want to use make -j$(nproc) … here.)
There was a problem hiding this comment.
Tried it, make -j$(nproc) works, using make you cannot compile a subset of files like when using ninja.
There was a problem hiding this comment.
using make you cannot compile a subset of files like when using ninja.
so you're saying the generated makefile builds too many files?
There was a problem hiding this comment.
Yes, but there's no harm in that. Other than some cpu cycles.
There was a problem hiding this comment.
we can consider changing that in phase two, just now I want to focus on getting this to work...
.travis.yml
Outdated
| @@ -108,6 +112,20 @@ before_script: | |||
| sudo make install | |||
| ) | |||
| fi | |||
| if [ "$TRAVIS_OS_NAME" = linux -a "$BORINGSSL" ]; then | |||
| (git clone https://boringssl.googlesource.com/boringssl && | |||
There was a problem hiding this comment.
git clone --depth=1 …… if you don't rewind to the latest tag or any blessed revision, using a shallow clone will be faster.
|
Hm, the build works now, but we get memory leakage from inside boringssl. I'll try to reproduce this locally and see what's going on. |
bagder
force-pushed
the
bagder/travis-boringssl
branch
from
37a961f
to
a367e34
Compare
|
It seems to be a false positive on thread-local memory, possibly caused by a buggy/old valgrind version. Since we already run many tests with valgrind enabled, I figured switching it off for the boringssl build is an okay work-around. |
|
Remains the issue of what revision to pick for tests. In the ticket leading up to this one I suggested to not go with HEAD because sometimes breaking changes occur (which sometimes are reverted, sometimes not). edit: Absent any better suggestion I'd like to repeat mine: Rewind to the latest tag for cocoapods, or any that matches |
The debug option causes far too many warnings in boringssl headers. Valgrind triggers some false positive errors in thread-local data used by boringssl.
|
I asked David Benjamin and he said:
... so I figure we can try doing that and see how it goes. |
|
Good enough for me. Thanks! |
|
The build looks red here only because I cancelled all the non-boringssl builds. I'll proceed and merge this into master now... |
No description provided.