Move the transition to downloading after the torrent has been checked
for being finished. This prevents a spurious state_changed_alert when
adding a torrent which is already completed.
Also move the posting of the torrent_checked_alert to maintain the
historical ordering of that alert with respect to the transition out of
checking_resume_data.
This alert's priority must be higher than `block_downloading_alert`'s
to allow custom handling of file errors.
With progress notifications enabled, network thread might fully load
alerts queue, so file errors from disk thread won't have a chance to
be delivered.
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
Don't allow peer connection to ask quota from bandwidth manager if send buffer is empty.
Remove undefined member function
Update download rate multiplier
Concerning type traits, the C++ standard states: "The behavior of a program
that adds specializations for any of the templates defined in this subclause is
undefined unless otherwise specified."
There is no exception for is_integral.
`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.
Most status alerts should have priorities above normal level. Good reason for this is resume data verification case. For a large torrent(having lots of pieces) whole alert queue will be overflowed
with a `piece_finished_alert` right after resume data has been verified. Thus alerts like `torrent_checked_alert`, `torrent_finished`, `state_changed_alert` will not go the alerts queue.
* Introduce alert_priority enumeration
* Bump state_changed_alert's priority
* Set dht_direct_response_alert priority to `critical`
arvidn