drop autotools support and dependencies requiring it #69
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vszakats
force-pushed
the
delete-autotools
branch
from
0d9bd15
to
1a1e4ed
Compare
autotools has been broken for certain platform since last autumn. This seems to be due to libtool limitations and generally being inflexible, slow and almost impossible to touch in upstream projects. autotools support also seems to require upstream to bundle runnable external code into source tarballs, making reproducibility hard, and sneaking in backdoors easy. Autotools is also slow even compared to CMake. It doesn't support single pass building of shared/static, and has other limitations which appear historical and without any hope/desire to be changed. - wolfssl has been broken with libssh2 for a year, with no interest in fixing it. wolfssl tests had to be disabled to pass CI. It's also notoriously complicated to configure. It has support for CMake, but it lags behind autotools, and not getting much/any updates upstream. - wolfssh requires wolfssl
vszakats
force-pushed
the
delete-autotools
branch
from
19326dc
to
9c8da4a
Compare
It was previously pulled by autopoint as a dependency.
vszakats
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
wolfSSL: libssh2_session_handshake failed: -12/-44 DECRYPT/ENCRYPT libssh2/libssh2#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.