This caused us to build everything 2-4 times, now we only build it 1-2
times (depending on selection of static/shared builds). The disadvantage
is that now it's more up to the reviewer to ensure modularity (we still
catch it in the bazel build, though).
This way, developers compile toxcore, toxav, and toxencryptsave as C++ at
least once at home, reducing the likelyhood of running into travis
failures where we compile as C++ in the windows build.
This library contains all the code for the old libtoxcore, libtoxav,
libtoxdns, and libtoxencryptsave. The build for toxav is still optional,
and disabling it causes libtoxcore to simply not contain those symbols
and the pkg-config file to not include opus and vpx as dependencies.
this updates the version-sync script to generate proper SO versions
which will be used by cmake and libtool to create version symlinks
on the system when a library is installed as well as setting the SO
version in the binary.
To see what this does, you have to configure tox with a prefix:
./configure --prefix=/tmp/tox-with-libtool
mkdir cbuild && cd cbuild && cmake -DCMAKE_INSTALL_PREFIX=/tmp/tox-with-cmake ..
Then run `make && make install`.
in both instances you should see the following installed in `lib/`:
libtoxcore.so -> libtoxcore.so.1.4.0
libtoxcore.so.1 -> libtoxcore.so.1.4.0
libtoxcore.so.1.4.0
inside the binary the soname should be the one with .1 and it should not
contain the full version:
$ objdump -p libtoxcore.so.1.4.0 | grep SONAME
SONAME libtoxcore.so.1
We disable the ones that fire, so we can use -Werror. We can then
investigate each warning individually and see whether to fix it or to
keep silencing it.
Compiling as C++ changes nothing semantically, but ensures that we don't
break C++ compatibility while also retaining C compatibility.
C++ compatibility is useful for tooling and additional diagnostics and
analyses.
It is still C code, so still compatible with C compilers as well. This
change lets us see more clearly where implicit conversions occur by
making them explicit.
