tidy-up: delete unused build configuration settings #9044
Conversation
vszakats
added
build
feature-window
|
How did you find these? Can we create a script or test or something for this? |
|
@bagder It was a byproduct of an effort in syncing autotools-cmake-Makefile.m32 builds to produce the exact same binaries 1. I dumped command-line Some unused settings are still being generated by It's probably possible to automate this to some extent: The source for most of these settings is Footnotes |
|
Here's a rough attempt to automate it: #!/bin/sh
autoheader configure.ac # generate lib/curl_config.h.in
{
grep -o -E 'set\([A-Z][A-Z0-9_]{3,}' CMake/Platforms/WindowsCache.cmake | sed -E 's|set\(||g'
grep -o -E -h '#define +[A-Z][A-Z0-9_]{3,}' lib/config-*.h | sed -E 's|#define +||g'
grep -o -E '#cmakedefine +[A-Z][A-Z0-9_]{3,}' lib/curl_config.h.cmake | sed -E 's|#cmakedefine +||g'
grep -o -E '#undef +[A-Z][A-Z0-9_]{3,}' lib/curl_config.h.in | sed -E 's|#undef +||g'
} | sort -u | grep -v -F 'HEADER_CURL_' | while read -r def; do
c="$(git grep -w -F "${def}" | grep -v -E -c '(/libcurl\.tmpl|^lib/config-|^lib/curl_config\.h\.cmake|^CMakeLists\.txt|^CMake/Platforms/WindowsCache\.cmake|^packages/vms/config_h\.com|^m4/curl-functions\.m4|^acinclude\.m4|^configure\.ac)')"
if [ "${c}" = '0' ]; then
echo "${def}"
fi
doneThis misses some After a few tweaks the results are not so bad. It missed these few unique cases: Some of these may be used by external headers (e.g. |
vszakats
changed the title
|
I think the HAVE_ ones at least should be ok. OPENSSL_NO_KRB5 is only defined by config-dos but I'm not sure why as I'd expect it to be defined by opensslconf.h. |
vszakats
added
tidy-up
and removed
feature-window
…skip]
AppVeyor CI (Debian):
real
------
Makefile.m32 40m53s (=2453s) 100% https://ci.appveyor.com/project/curlorg/curl-for-win/builds/44066230
CMake 50m11s (=3011s) 123% https://ci.appveyor.com/project/curlorg/curl-for-win/builds/44062838
Same on local machine (macOS):
real user sys space
------ ------ ------ ---------
Makefile.m32 29m40s (=1780s) 100% 34m50s 7m48s 909343242 bytes
CMake (with PR 9044) 36m59s (=2219s) 125% 41m58s 9m26s 973999614 bytes
CMake 37m18s (=2238s) 126% 42m12s 9m25s 973829216 bytes
autotools (with PR 9044) 43m01s (=2581s) 145% 46m50s 11m18s 984571419 bytes
autotools 44m06s (=2646s) 149% 48m11s 11m47s 984477038 bytes
Ref: curl/curl#9044
Yeah, that feels like an overstep. We should leave openssl to define those things. |
No longer used since de71e68.
This is necessary only for MFC (Microsoft Foundation Class) DLLs to force linking MFC components statically to the DLL. libcurl.dll does not use MFC, so this define can be deleted. Ref: https://docs.microsoft.com/cpp/build/regular-dlls-statically-linked-to-mfc
There are more instances of this in autotools, but I did not dare to touch those. Looked like it is used to detect socket support.
FIXME: Possibly the related comment can also be deleted in
packages/vms/generate_config_vms_h_curl.com
|
Rebased onto master. |
|
@bagder: At this point this is committable. The few FIXMEs are rather questions, that are beyond my insight to touch. Do you think I shall continue with this PR? |
Switch from `curl-gnumake.sh` to `curl-cmake.sh` with upcoming curl release v8.5.0. cmake builds are now _faster_ for Windows builds than raw gnumake (aka `Makefile.mk`). They also use 'unity' mode, which makes builds run fast with the side-effect of also creating potentially more efficient binaries by allowing better compiler optimizations. This also makes curl-for-win use the same build system for all target platforms (`Makefile.mk` is not available for *nix platforms). Initially on 2022-07-04 cmake was 25% slower than gnumake. By 2022-09-26 this reduced to 20%, by 2023-07-29 to 18% and after the latest round of updates gnumake came out 7% slower than cmake. This is for Windows, for a triple x64, arm64 and x86 build. In absolute times this is 27m22s for cmake and 29m11s for gnumake. (FWIW autotools builds are 52% slower than cmake unity builds now.) Making cmake builds fast was a multi-year effort with these major steps: 1. add support for cmake builds in curl-for-win. 420e73c 2. bring it in-line with gnumake and autotools builds and tidy-up as much as possible. Scattered to a many commits. 3. delete a whole bunch of unused feature detections. curl/curl@4d73854 curl/curl#9044 (and a lot more smaller commits) 4. speed up picky warning option initialization by avoiding brute-force all options. (first in libssh2, then in curl, then applied also ngtcp2, nghttp3, nghttp2) curl/curl@9c543de curl/curl#10973 5. implement single build run for shared and static libcurl + tool (first in libssh2) curl/curl@1199308 curl/curl#11505 53dcd49 6. implement single build pass for shared and static libcurl (for Windows initially) curl/curl@2ebc74c curl/curl#11546 7. extend above to non-Windows (e.g. macOS) curl/curl@fc9bfb1 curl/curl#11627 bafa77d (mac) 1b27304 (linux) 8. implement unity builds: single compiler invocation for libcurl + tool curl/curl@3f8fc25 curl/curl#11095 curl/curl@f42a279 curl/curl#11928 67d7fd3 9. speed up 4x the cmake initialization phase (for Windows) curl/curl@2100d9f curl/curl#12044 10. speed up cmake initialization even more by pre-filling detection results for our well-known mingw-w64 environments. 74dd967 5a43c61 +1: speed up autotools initialization by mitigating a brute-force feature detection on Windows. This reduced total build times by 5 minutes at the time, for the 3 Windows targets in total. curl/curl@6adcff6 curl/curl#9591 Also update build times for cmake-unity and gnumake, based on runs: cmake-unity: https://ci.appveyor.com/project/curlorg/curl-for-win/builds/48357875 gnumake: https://ci.appveyor.com/project/curlorg/curl-for-win/builds/48358005
Delete unused macros (most of them feature guards):
CURL_INCLUDES_SYS_UIO[1]HAVE_ALLOCA_H[2]HAVE_CRYPTO_CLEANUP_ALL_EX_DATA(unused since de71e68)HAVE_DLFCN_HHAVE_DLOPENHAVE_DOPRNTHAVE_FCNTLHAVE_GETHOSTBYNAME[3]HAVE_GETOPT_HHAVE_GETPASSHAVE_GETPROTOBYNAMEHAVE_GETSERVBYNAMEHAVE_IDN_FREE*HAVE_INET_ADDRHAVE_IOCTLHAVE_KRB4HAVE_KRB_GET_OUR_IP_FOR_REALMHAVE_KRB_HHAVE_LDAPSSL_HHAVE_LDAP_INIT_FDHAVE_LIBDLHAVE_LIBNSLHAVE_LIBRESOLV*HAVE_LIBUCBHAVE_LLHAVE_LOCALTIME_RHAVE_MALLOC_HHAVE_MEMCPYHAVE_MEMORY_HHAVE_NETINET_IF_ETHER_HHAVE_NI_WITHSCOPEIDHAVE_OPENSSL_CRYPTO_HHAVE_OPENSSL_ERR_HHAVE_OPENSSL_PEM_HHAVE_OPENSSL_PKCS12_HHAVE_OPENSSL_RAND_HHAVE_OPENSSL_RSA_HHAVE_OPENSSL_SSL_HHAVE_OPENSSL_X509_HHAVE_PEM_HHAVE_POLLHAVE_RAND_SCREENHAVE_RAND_STATUSHAVE_RECVFROMHAVE_SETSOCKOPTHAVE_SETVBUFHAVE_SIZEOF_LONG_DOUBLEHAVE_SOCKIO_HHAVE_SOCK_OPTSHAVE_STDIO_HHAVE_STRCASESTRHAVE_STRFTIMEHAVE_STRLCATHAVE_STRNCMPIHAVE_STRNICMPHAVE_STRSTRHAVE_STRUCT_IN6_ADDRHAVE_TLD_HHAVE_TLD_STRERRORHAVE_UNAMEHAVE_USLEEPHAVE_WINBER_HHAVE_WRITEVHAVE_X509_HLT_OBJDIRNEED_BASENAME_PROTONOT_NEED_LIBNSLOPENSSL_NO_KRB5RECVFROM_TYPE*SIZEOF_LONG_DOUBLESTRERROR_R_TYPE_ARG3USE_YASSLEMUL_USRDLL(from CMake) [4][1] Maybe some related parts in
m4/curl-functions.m4andconfigure.accould also be deleted?[2] Maybe the related comment can also be deleted in
packages/vms/generate_config_vms_h_curl.com[3] There are more instances of this in autotools, but I did not dare to
touch those. Looked like it is used to detect socket support.
[4] This is necessary for MFC (Microsoft Foundation Class) DLLs to
force linking MFC components statically to the DLL.
libcurl.dlldoes not use MFC, so this define can be deleted.
Ref: https://docs.microsoft.com/cpp/build/regular-dlls-statically-linked-to-mfc
Closes #xxxx