wolfssl: cmake support lagging far behind autotools and not getting
features/updates. autotools is complicated to tune for curl/libssh2.
wolfssl support in libssh2 has been broken for a year with not much
interest or a fix in sight.
https://github.com/libssh2/libssh2/issues/1020
wolfssl-based CI tests are kept disabled to make the build pass.
wolfssh: requires autotools and wolfssl.
autotools build method for: curl, libssh2, libressl.
curl's CMake support is now first class (with few PRs pending).
libssh2 got its CMake overhauled and on par with autotools.
Both support unity builds. LibreSSL already had pretty good
CMake support and with some kinks fixed recently, it's now
working without any issue.
CW_DEV_CROSSMAKE_REPRO dev/debug build option.
I used this to sync up cmake/autotools/gnumake builds in the
past few years. This process was completed with success, allowing
to drop gnumake completely and making autotools redundant.
From time to time it's useful to compare builds made with different
build tools, but the benefits aren't high enough to justify maintaining
autotools as a build tool here just for that.
Autotools has been broken for certain configs in curl-for-win since
autumn, after introducing Linux MUSL builds. After many weeks of
trying, fixing it seems impossible. Possibly because of libtool. Besides
this specific issue, autotools turned out to be inflexible, slow,
unnecessarily complex, buggy, opaque, with practically unreadable
source code, also difficult to edit, and with no clear "best practices"
to follow.
Autotools support also seems to be coming historically with external
runnable code bundled into source tarballs, making reproducibility
difficult, and sneaking in backdoors easy. See CVE-2024-3094.
Autotools is also slow even compared to CMake. It doesn't support
single-pass builds for shared/static libs, and has other limitations
which appear historical and without any hope/desire to ever change.
Windows support is also pretty much accidental, and by being based
on arcane not-even-POSIX shell/utilities, it's not natively supporting
it anyway and never will.
This also means that curl-for-win builds will not attempt to support
dependencies that require autotools. But, this also means that this
may give way for supporting new build tools in the future.
remove support for:
gsasl: requires autotools.
libidn2: requires autotools.
wolfssl: cmake support lagging far behind autotools and not getting features/updates. autotools is complicated to tune for curl/libssh2. wolfssl support in libssh2 has been broken for a year with not much interest or a fix in sight. https://github.com/libssh2/libssh2/issues/1020 wolfssl-based CI tests are kept disabled to make the build pass.
wolfssh: requires autotools and wolfssl.
autotools build method for: curl, libssh2, libressl. curl's CMake support is now first class (with few PRs pending). libssh2 got its CMake overhauled and on par with autotools. Both support unity builds. LibreSSL already had pretty good CMake support and with some kinks fixed recently, it's now working without any issue.
CW_DEV_CROSSMAKE_REPROdev/debug build option. I used this to sync up cmake/autotools/gnumake builds in the past few years. This process was completed with success, allowing to drop gnumake completely and making autotools redundant. From time to time it's useful to compare builds made with different build tools, but the benefits aren't high enough to justify maintaining autotools as a build tool here just for that.Autotools has been broken for certain configs in curl-for-win since autumn, after introducing Linux MUSL builds. After many weeks of trying, fixing it seems impossible. Possibly because of libtool. Besides this specific issue, autotools turned out to be inflexible, slow, unnecessarily complex, buggy, opaque, with practically unreadable source code, also difficult to edit, and with no clear "best practices" to follow.
Autotools support also seems to be coming historically with external runnable code bundled into source tarballs, making reproducibility difficult, and sneaking in backdoors easy. See CVE-2024-3094.
Autotools is also slow even compared to CMake. It doesn't support single-pass builds for shared/static libs, and has other limitations which appear historical and without any hope/desire to ever change. Windows support is also pretty much accidental, and by being based on arcane not-even-POSIX shell/utilities, it's not natively supporting it anyway and never will.
This also means that curl-for-win builds will not attempt to support dependencies that require autotools. But, this also means that this may give way for supporting new build tools in the future.