* Bump minimum Qt version to 5.6
* Switch from QRegExp to QRegularExpression
While still available, QRegExp has been moved to Qt6::Core5Compat module
and is not part of Qt6::Core.
* Use qIsEffectiveTLD instead of QUrl::topLevelDomain
The latter is not part of Qt6::Core. The former is a private utility in
Qt6::Network; using it for now, until (and if) we switch to something
non-Qt-specific.
* Use QStyle::State_Horizontal state when drawing progress bars
Although available for a long time, this state either didn't apply to
progress bars before Qt 6, or was deduced based on bar size. With Qt 6,
failing to specify it results in bad rendering.
* Don't use QStringRef (and associated methods)
While still available, QStringRef has been moved to Qt6::Core5Compat
module and is not part of Qt6::Core. Related method (e.g.
QString::midRef) have been removed in Qt 6.
* Use Qt::ItemIsAutoTristate instead of Qt::ItemIsTristate
The latter was deprecated and replaced with the former in Qt 5.6.
* Don't use QApplication::globalStrut
This property has been deprecated in Qt 5.15 and removed in Qt 6.
* Use QImage::fromHICON instead of QtWin::fromHICON
WinExtras module (providind the latter helper) has been removed in Qt 6.
* Use QStringDecoder instead of QTextCodec
While still available, QTextCodec has been moved to Qt6::Core5Compat
module and is not part of Qt6::Core.
* Don't forward-declare QStringList
Instead of being a standalone class, its definition has changed to
QList<QString> template specialization in Qt 6.
* Use explicit (since Qt 6) QFileInfo constructor
* Use QDateTime's {to,from}SecsSinceEpoch instead of {to,from}Time_t
The latter was deprecated in Qt 5.8 and removed in Qt 6.
* Don't use QFuture<>'s operator==
It has been removed in Qt 6. Since the original issue this code was
solving was caused by future reuse, just don't reuse futures and create
new finished ones when necessary.
* Use std::vector<> instead of QVector<>
The latter has been changed to a typedef for QList<>, which might not be
what one wants, and which also changed behavior a bit leading to
compilation errors.
* Don't use + for flags, cast to int explicitly
Operator+ for enum values has been deleted in Qt 6, so using operator|
instead. Then, there's no conversion from QFlags<> to QVariant, so need
to cast to int.
* Support Qt 6 in CMake and for MSI packaging
* Remove extra (empty) CMake variable use when constructing Qt target names
* Simplify logic in tr_qt_add_translation CMake helper
Co-authored-by: Charles Kerr <charles@charleskerr.com>
Port libtransmission to C++. This PR doesn't refactor everything to c++.
Its code changes are only what was necessary to compile and link as c++.
See libtransmission/README.md for details on how to submit modernization
patches!
Co-authored-by: Mike Gelfand <mikedld@mikedld.com>
* Support .git files (e.g. for worktrees, submodules)
* Fix symlinks in source tarball, switch to TXZ, adjust non-release name
* Remove autotools stuff
* fix: __attribute__(__printf__) warnings
* fix: implicit fallthrough warning
* fixup! fix: implicit fallthrough warning
* fix: disable warnings for 3rd party code
Since we want to leave upstream code as-is
* fixup! fix: disable warnings for 3rd party code
* fixup! fix: disable warnings for 3rd party code
* silence spurious alignment warning
Xrefs
Discussion: https://stackoverflow.com/a/35554349
Macro inspiration: 90ac46f710/f/src/util/util_safealign.h (_35)
* fixup! fix: disable warnings for 3rd party code
* fixup! fix: implicit fallthrough warning
* make uncrustify happy
* remove uncrustify-test.sh
that's probably off-topic for this PR
* fixup! fix: __attribute__(__printf__) warnings
* Update libtransmission/CMakeLists.txt
Co-Authored-By: ckerr <ckerr@github.com>
* fixup! silence spurious alignment warning
* use -w for DISABLE_WARNINGS in Clang
* refactor: fix libtransmission deprecation warnings
* fix: pthread_create's start_routine's return value
This was defined as `void` on non-Windows but should have been `void*`
* chore: uncrustify
* fix: add DISABLE_WARNINGS option for SunPro Studio
* fix "unused in lambda capture" warnings by clang++
* fix 'increases required alignment' warning
Caused from storing int16_t's in a char array.
* fix net.c 'increases required alignment' warning
The code passes in a `struct sockaddr_storage*` which is a padded struct
large enough for the necessary alignment. Unfortunately it was recast as
a `struct sockaddr*` which has less padding and a smaller alignment. The
warning occrred because of these differing alignments.
* make building quieter so warnings are more visible
* fixup! fix 'increases required alignment' warning
* Fix -Wcast-function-type warnings in GTK+ app code
https://gitlab.gnome.org/GNOME/gnome-terminal/issues/96 talks about both
the issue and its solution.
GCC 8's -Wcast-function-type, enabled by -Wextra, is problematic in glib
applications because it's idiomatic there to recast function signatures,
e.g. `g_slist_free(list, (GFunc)g_free, NULL);`.
Disabling the warning with pragmas causes "unrecognized pragma" warnings
on clang and older versions of gcc, and disabling the warning could miss
actual bugs. GCC defines `void (*)(void)` as a special case that matches
anything so we can silence warnings by double-casting through GCallback.
In the previous example, the warning is silenced by changing the code to
read `g_slist_free(list, (GFunc)(GCallback)g_free, NULL);`).
* fixup! fix "unused in lambda capture" warnings by clang++
* fixup! fix "unused in lambda capture" warnings by clang++
* fix two more libtransmission compiler warnings
* fix: in watchdir, use TR_ENABLE_ASSERTS not NDEBUG
Previously building with `cmake -G Ninja` would fail with this error:
ninja: error: 'third-party/event-c51b159cff/lib/libevent.a', needed by
'libtransmission/transmission-test-watchdir_generic', missing and no
known rule to make it
This was due to missing BUILD_BYPRODUCTS in the calls to
ExternalProject_Add(), as discussed here:
<https://cmake.org/pipermail/cmake/2015-April/060234.html>
Standard Windows programs (e.g. Explorer) tolerate this, but some other
programs (e.g. Firefox) are more strict in how they retrieve version
information and may fail if language IDs in StringFileInfo and VarFileInfo
don't match.
It was announced on March 5th that CyaSSL changes name to WolfSSL,
and version 3.4.0 has been released under that new name. Tune
FindCyaSSL.cmake a bit to probe for both libraries. Fortunately,
compatibility headers are provided so I didn't have to touch the
code at all for now.
There're too many functions and types to consider, and benefits of not
using LFS macros aren't that big (I was thinking of using fts(3) but
that may not happen soon or at all).
Some crypto libraries (like CyaSSL, MatrixSSL and CommonCrypto) either
don't have or expose this functionality at all, expose only part of it,
or (like OpenSSL) have heavyweight API for it. Also, for the task as
easy as BASE64 encoding and decoding it's much better to use small and
simple specialized library.
Charles Kerr