Allow using system libraries.

[jeandudey]

Fixes #152.

For example, when the dependencies are available on the system one could do:

qmake CONFIG+=config_without_bundled_cppzmq \
      CONFIG+=config_without_bundled_robin_hood \
      CONFIG+=config_without_bundled_secp256k1 \
      LIBS+=-lrocksdb \
      LIBS+=-lsimdjson

And it would choose the system libraries, some distributions (like Guix, Debian, etc.) may remove the bundled code, so, means to use system libraries are needed.

[cculianu]

Looks like the right approach although I’m currently traveling and unable to test this readily. May take a few days to merge but looks good so far in terms of approach.

[jeandudey]

@cculianu hey! sorry for bothering just pinging in case you forgot about this

[cculianu]

Yeah sorry I still need to review this. I feel a bit like "who the hell installs robin_hood in the system and why does it matter".. same for simdjson. These are all basically... header-only and who cares.

[jeandudey]

Probably nobody installs robin-hood-hashing but at Guix there's package for it which builds with CMake and installs the configuration files needed to search for it so that other projects don't bundle it. Guix also distributes the sources of a program (required by Fulcrum GPL) so in the end most projects that contain bundled libraries will end up with duplicated files.

For example p2pool also bundles robin-hood-hashing and p2pool is also present on Guix, I've yet have to modify it to use the system's robin-hood-hashing library.

For the simdjson case, it can be built as a shared library too and other programs could load it too.

---

I mean this patch doesn't have to be accepted as this is applied when downloading sources at Guix anyway (see https://issues.guix.gnu.org/66120) but would reduce maintenance of the package to just pass the command line options instead of patching and doing that too.

[cculianu]

Ah ok.. I wasn't aware anybody needed this. Ok will review this soon.

I was a bit off-put by switching #include "thing.h" -> #include <thing.h> in some of the files but I guess there is no way around that. Makes me nervous that if the system has the header by accident, Fulcrum will pick that header and then I get users sending me bug reports that it failed to compile because link error etc etc etc... :/

[jeandudey]

I was a bit off-put by switching #include "thing.h" -> #include <thing.h> in some of the files but I guess there is no way around that.

I don't think it'd affect much since simdjson needs to be opted in and the others are truly header only libraries.