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