Given #385, ODB will now be compiled by the user locally. This poses a problem on Travis as
- downloading build2
- building build2
- downloading odb
- building odb
takes a lot of time (compared to Thrift and GTest which are trivial time, a minute or so at most).
Travis has a caching feature which should be investigated. Given that we are pegged to a Build2 version in the guide, we could:
- once download Build2
- install it in the Travis environment
- download ODB
- compile ODB
- install it in the environment
What could be cached is the installed ODB libraries (and its dependency libs). Build2 can be scrapped afterwards by the VM shutdown. In case a newer ODB release happens during our time (and hence the automated install would download a different code...!), the cache has to be set up to redownload Build2 and ODB and do the whole thing over again.
Actually, this could be done for Thrift, too!
Given #385, ODB will now be compiled by the user locally. This poses a problem on Travis as
takes a lot of time (compared to Thrift and GTest which are trivial time, a minute or so at most).
Travis has a caching feature which should be investigated. Given that we are pegged to a Build2 version in the guide, we could:
What could be cached is the installed ODB libraries (and its dependency libs). Build2 can be scrapped afterwards by the VM shutdown. In case a newer ODB release happens during our time (and hence the automated install would download a different code...!), the cache has to be set up to redownload Build2 and ODB and do the whole thing over again.
Actually, this could be done for Thrift, too!