There seem to be support (apparently on the Windows platform) for an alternate, BSD-style TCP/IP API called lwIP, enabled via USE_LWIPSOCK. Some of its types are different. Not sure if this is actively used, or even universally supported in curl.

We have some partial support for lwip. I don't know how complete that is.

I plan to make this way of setting type types generic enough to work with that if someone wants to get a build like that going anyway.

I will let the dedicated config-[platform].h files define the types like today, remove the checks from configure/cmake and then have "fallback defines" in functypes.h that will default to the POSIX types - unless other types are defined.

On my Linux host, running configure with and without this patch shows no particular speed difference and individual timing differences between invokes is larger (my default build configure line takes ~18 seconds to complete).

Presumably this is because after @vszakats's recent optimization it just a few compiles less and they are very fast here.

It should now also be faster when using CMake on non-Windows. That one was previously favoring Windows, and the "unlucky" case was Linux and other platforms.

Either way, it feels much better just to look at the new solution. It will also surely save some energy for all.

I run more curl-for-win tests (without this PR), and CMake has a 20% overhead compared to Makefile.m32, autotools has 30%. (being 42% before, and even 50% a few months ago.) One reason is that libcurl is compiled twice with cmake/autotools, plus the still quite resource intensive auto-detection phases (also run twice with both cmake/autotools).

One (off-topic) way to improve the above, if libcurl objects would be compiled just once and being re-used for both the dynamic and static libs. Technically doable, but no idea how with cmake/autotools [*]. There is also a built-in second compilation pass of libcurl (named libcurlu) when tests are enabled in autotools.

[*] autotools likely can do this, but with pitfalls, like no option (that I could discover) to chose which lib flavor to link with curl.

Either way, it feels much better just to look at the new solution. It will also surely save some energy for all.

I too think this feels like a much cleaner and nicer solution. It will however probably cause build breakages in the short-term on some fringe platforms. They should be easy to fix though.

/off I've seen a suggestion on the mailing list to use caching with autotools and cmake. For CI and curl-for-win these don't seem to be useful by default and have many pitfalls, but with manual/fragile uncaching + hacks, they helped reducing curl-for-win build times by a little bit. Estimated 2 minutes total with CMake (-5%), and ~45 seconds with autotools (-1–2%). I'm guessing the reason for the mild results with autotools is that it misses caching quite a few detection results. [1] [2]

Yes, we can/should still work on improved caching.