1. The imported target properties may not contain -D switches in the
INTERFACE_COMPILE_DEFINITIONS property, because CMake will always
prepend them to each item. Therefore we have to remove those switches
and also pass other options (e.g. -fexceptions) in INTERFACE_COMPILE_OPTIONS
property, otherwise CMake creates "mutants" '-D-fexceptions' alike.
2. FindOpenSSL.cmake variable for include directory is
OPENSSL_INCLUDE_DIR, not OPENSSL_INCLUDE_DIRS.
1. Replace custom 'shared' option with the standard BUILD_SHARED_LIBS
flag
2. Replace foreach() calls for source items with target_sources() and
generator expression $<JOIN:>.
3. Remove build types definition: makes no sense for
single-configuration generators, and is populated automatically for
multi-configuration ones.
4. Add feature summary
5. Enahnce compiler flags management for static runtime by utilizing functions
from the ucm project
6. Copy almost all options from the Jamfile.
7. If compiler supports C++14, use it.
8. Raise minimum required CMake version to 3.11 and drop bundled FindIconv.cmake
`PC_LIBTORRENT_RASTERBAR_CFLAGS` not only gives you the definitions, but
also includes the include path flags (`-I...`).
This causes problesm when passing the result to
`target_compile_definitions`. The resulting compiler command would then
look something like this:
/usr/bin/c++ -D-I/home/...
This change uses `PC_LIBTORRENT_RASTERBAR_CFLAGS_OTHER` instead which
does not contain the include path flags.
File locking interacts poorly with the path to replace a read only file handle
with a read/write one. For performance reasons the old handle is not closed
until the new one is put in place. With file locking this obviously cannot
work because the first handle is holding a lock on the file. As a result,
file_pool::open_file fails in this case. Even if we dropped the reference to
the read only file handle before attempting to re-open it, the open could still
fail if another thread is holding a reference to the read only handle.
There doesn't seem to be a good way around this. The simple solution would be
to always open files in read/write mode, but that has obvious safety downsides.
Any other solution would significantly complicate the file pool code.
Deprecating file locking seems to be the least bad option.
Eugene Shalygin