Refactors many things in cmake to improve and simplify:
- don't use variable indirection for target names; target names are
*already* a variable of sorts. (e.g. ${UTIL_LIB} is now just
lokinet-util). cmake/basic_definitions.cmake is now gone.
- fix LTO enabling to use the standard cmake (3.9+) LTO mechanism rather
than shoving a bunch of flag hacks through link_libraries and
add_compile_options. This also now enables LTO when building a shared
library (because previously the -flto hacks were only turned on in the
static code for some reason).
- build liblokinet as *either* shared library or static library, but not
both. Building both makes things more complicated because they had
different names (lokinet-shared or lokinet-static) and seems pointless:
you generally want one or the other. Now there is just the liblokinet
target, which will be shared or static depending on the value of
BUILD_SHARED_LIBS.
- Simplify lokinet-cryptography AVX2 code: just build *one* library, and
add in the additional AVX2 files when possible, rather than building two
and needing to merge them.
- Compress STATIC_LINK and STATIC_LINK_RUNTIME into just STATIC_LINK.
It makes no sense to use one of these (_RUNTIME) on Windows and the
other on non-Windows when they appear to try to do the same thing.
- remove a bunch of annotations from `endif(FOO)` -> `endif()`.
- move all the tuntap compilation code (including OS-specific source
file selection) into vendor/CMakeLists.txt and build tuntap as an
intermediate OBJECT library rather than keeping a global variable in 5
different files.
- move release motto define to root cmake; it made no sense being
duplicated in both unix.cmake and win32.cmake
- fix add_log_tag to not stomp on any existing source compile flags with
its definition. Also use proper compile definition property instead of
cramming it into compile flags.
- make optimization/linker flags less hacky. There's no reason for us
to force particular optimization flags because the cmake build type
already does that (e.g. -DCMAKE_BUILD_TYPE=Release does -O3). Not doing
that also silences a bunch of cmake warnings because it thinks "-O0 -g3"
etc. are link libraries (which is reasonable: that's what the code was
telling cmake they are).
- sets the default build type to RelWithDebInfo which gives us `-O2 -g`
if you don't specify a build type.
- Move PIC up (so that the things loaded in unix.cmake, notably libuv,
have it set).
- Add a custom `curl` interface library that carries the correct link
target and include paths for curl (system or bundled).
This commit reflects changes to clang-format rules. Unfortunately,
these rule changes create a massive change to the codebase, which
causes an apparent rewrite of git history.
Git blame's --ignore-rev flag can be used to ignore this commit when
attempting to `git blame` some code.
- util::Mutex is now a std::shared_timed_mutex, which is capable of
exclusive and shared locks.
- util::Lock is still present as a std::lock_guard<util::Mutex>.
- the locking annotations are preserved, but updated to the latest
supported by clang rather than using abseil's older/deprecated ones.
- ACQUIRE_LOCK macro is gone since we don't pass mutexes by pointer into
locks anymore (WTF abseil).
- ReleasableLock is gone. Instead there are now some llarp::util helper
methods to obtain unique and/or shared locks:
- `auto lock = util::unique_lock(mutex);` gets an RAII-but-also
unlockable object (std::unique_lock<T>, with T inferred from
`mutex`).
- `auto lock = util::shared_lock(mutex);` gets an RAII shared (i.e.
"reader") lock of the mutex.
- `auto lock = util::unique_locks(mutex1, mutex2, mutex3);` can be
used to atomically lock multiple mutexes at once (returning a
tuple of the locks).
This are templated on the mutex which makes them a bit more flexible
than using a concrete type: they can be used for any type of lockable
mutex, not only util::Mutex. (Some of the code here uses them for
getting locks around a std::mutex). Until C++17, using the RAII types
is painfully verbose:
```C++
// pre-C++17 - needing to figure out the mutex type here is annoying:
std::unique_lock<util::Mutex> lock(mutex);
// pre-C++17 and even more verbose (but at least the type isn't needed):
std::unique_lock<decltype(mutex)> lock(mutex);
// our compromise:
auto lock = util::unique_lock(mutex);
// C++17:
std::unique_lock lock(mutex);
```
All of these functions will also warn (under gcc or clang) if you
discard the return value. You can also do fancy things like
`auto l = util::unique_lock(mutex, std::adopt_lock)` (which lets a
lock take over an already-locked mutex).
- metrics code is gone, which also removes a big pile of code that was
only used by metrics:
- llarp::util::Scheduler
- llarp:🧵:TimerQueue
- llarp::util::Stopwatch
This rewrites the version info using lokid's approach of compiling it
into a .cpp file that gets generated as part of the build (*not* during
the configure stage).
Among other things, this means that changing the version no longer
invalidates ccache or cmake dependencies, and because it depends on
`.git/index` git commits will cause the version to be regenerated,
making the commit tag more reliable (currently if you rebuild without
running cmake your git commit tag doesn't update).
resolvePath was leaking memory (the returned char * from realpath was
never freed), but upon closer inspection resolvePath doesn't seem right:
shell/glob/~ expansion is the job of the shell, not the argument (but
worse, if you pass it something like '~' (quoted) it would expand, which
is wrong.
Also de-duplicate some code.
