These were generated by the autotools build. Some clients may depend on
these files instead of the newer split pkg-config files. New clients
should be using the toxcore, toxav, toxencryptsave, and toxdns modules.
We also never really tested this, because we run make distcheck, which
does another configure with default flags instead of the ones we passed.
Fixes#317.
Having -Werror set by default causes users' builds to fail because
toxcore is not warning-free. Failing on errors is appropriate for the
development phase, e.g. when building it in a CI enviroment, but it
doesn't make much sense to fail builds for users and let them figure out
that they need to pass -DWARNINGS=OFF to make the library build.
This warning is triggered in `av_test.c`, where we have an open issue.
Silencing the warning locally would make the issue less visible. This
way, we will see the warning when we start removing the `-Wno-*` flags.
`new_nonce` has been an alias for `random_nonce` for a while now. Having
two names for the same operation is confusing. `random_nonce` better
expresses the intent. The documentation for `new_nonce` talks about
guaranteeing that the nonce is different from previous ones, which is
incorrect, it's just quite likely to be different.
Also, disable -pedantic on C++, because it's not really useful there,
and causes a lot of warnings on `enum FOO { BAR, };` (comma at end of
enumerator list).
Previously, all log messages generated by tox_new (which is quite a lot)
were dropped, because client code had no chance to register a logging
callback, yet. This change allows setting the log callback from the
beginning and removes the ability to unset it.
Since the log callback is forever special, since it can't be stateless,
we don't necessarily need to treat it uniformly (with `event`).
Hex constants make it clearer that you can only use 2 nibbles (the two
digits of the number, displayed as two columns in the source code), i.e.
1 byte, for the packet kind. It also makes the bit representation easier
to see.
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.
These definitely don't belong in a module called "crypto core". The DHT
module seems like the best place to put them, since they are sent to DHT
nodes.
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.
iphydf