Hi Christop,
Thanks for giving us a heads up
regarding the key life time.
I've read through:
(which is probably related to this
mail?)
and have some remarks:
- V8 does not provide a stable API
across versions, so you need exactly the version that we use (or
that release series).
- we apply some patches to V8, mostly
build system related, however some of them patch away some
"Resources empty? Geronimo!!!!" code which is not nice to have in
a database - that will auto-terminate without any feedback then.
- Rocksdb - same here. While we send
patches of our changes upstream, they may only become available in
later versions which may not be api compatible - so if I strongly
sugest to use the version shipped with arangodb.
- Boost - you most probably need the
version we use, it should be ok to use a system provided version
- snappy - whatever is newer probably
is better. needs to work with rocksdb.
- s2 (not yet in your list) - probably
needs to be exactly the shipped version with ArangoDB 3.4
- curl - you can probably use newer
versions.
- velocypack - our binary json
representation https://github.com/arangodb/velocypack/ - to be
honest we didn't yet work with tags here so you could identify
whats released with which arangodb - we need to fix this.
- fuerte - our binary transport c++
library - issues see velocypack.
- iresearch - needs to be a matching
version, however upstream is also maintained by us.
- ICU - we use the one bundled with V8
- don't know whether there is a good way to include a system one
Up to arangodb we used cpack to
generate debian packages, accompanying scripts can be found in
Installation/debian; This is probably why you don't find a debian/
directory.
With ArangoDB 3.4 we migrated to
statically linked binaries with libmusl - compile once, bundle
into tar/rpm/deb; The currently used debian scripts can be found
here: https://github.com/arangodb/oskar/tree/master/debian/3.4
Since we need to be able to ship bugfix
versions, we do this with the third version digit incrementing. So
Arangodb 3.3.20 can be treated as a bugfix version of 3.3.19.
The current arangodb cmake build is
intended to bundle and bring all required 3rd party libraries, I
don't know how well it can be configured to prefer system
installed ones.
If you have more questions regarding
compiling arangodb don't hesitate to ping me via slack or github
issues.
Cheers,
Willi
ps: there are only rspec / ruby tests
remaining which probably shouldn't be represented in the final
package, the ruby tag of the initial wnpp can probably be removed.
|