Compile a library from specified repo and revision

[mrc0mmand]

This PR adds a compile-before-test support for SSL/TLS libraries, which compiles the given library from specified repository before the testing itself. Due to limitations of Travis, this solution is a 'little' hack and it's sort of cumbersome, but it works (at least for now).

Current implementation does a check before the testing for a library-repo file in the root of the git repository. This file has following format:

export DEV_LIBRARY_NAME="gnutls"
export DEV_LIBRARY_REPO="https://gitlab.com/gnutls/gnutls.git"
export DEV_LIBRARY_BRANCH="gnutls_3_3_26"

Meaning of each variable is self-explanatory (DEV_LIBRARY_NAME can be gnutls, nss or openssl). If this file is found, it is sourced, content of each variable is checked and if it's a valid combination, the scripts/lib-compile.sh script is executed with the parsed settings.

This file contains a compilation and installation phase for each supported library. All these phases definitely need improvements, as they are a minimal working example. If the compilation succeeds, the usual testing phase is executed, otherwise the build is aborted and build/installation logs are printed to the Travis log.

Current issues:

• Usually, a specific library version is buildable on RHEL 7/Fedora, but not on RHEL 6 (and vice versa), thus the build always fails for some environments
• The compilation is executed in all jobs, thus each library is unnecessarily compiled three times for each OS version

Ideally, there should be some (unfortunately) external infrastructure, which would make scratch builds for each supported OS. which could be easily installed and tested.

As for the CI part - Travis does not support job-triggering by external repository [0], so this patch can be used in following scenarios:

• Create a separate branch with a library-specific configuration file (library-repo) and set Travis to periodically build this branch
• Touch and force-push the configuration file to the branch to trigger the rebuild manually

The second part could be easily scripted, but that would be another hack...

We discussed this solution with @ep69, but if we want to use only Travis, there's not much we can do to make this solution less hacky.

[0] travis-ci/travis-ci#631

[tomato42]

while travis job can't be triggered by other repo, it can be triggered by internal timer. Given the frequency of updates to those repos, triggering on every update probably would be excessive anyway. I've configured it to build once a week for now.

Why use a specific branch and not master?