After this patch curl requires targeting Vista or newer, and a toolchain
with Vista support.
Supported MSVC compilers (VS2010+) all support Vista:
- VS2012+ target Win8 (or later) by default.
- VS2010 targets Win7 by default.
Supported mingw-w64 versions (v3+) all support Vista:
- mingw-w64 v9+ target Win10 by default.
- mingw-w64 v8 and older target Server 2003 (~XP) by default.
After this patch it may be necessary to override the default Windows
target version to Vista (or newer) via:
autotools: `CPPFLAGS=-D_WIN32_WINNT=0x0600`
cmake: `-DCURL_TARGET_WINDOWS_VERSION=0x0600`
- mingw-w64 v6+ allow changing the default at toolchain build-time.
Notes:
- For non-MSVC, non-mingw-w64 toolchains, `if_nametoindex` needs to be
allowlisted in `curl_setup.h`, if they do support it.
Fixes#17985 (discussion)
Closes#18009
To simplify the directory layout.
- OS400 and vms support move from `packages` to `projects`.
- Windows README and `generate.bat` files move from `projects`
to `projects/Windows`.
Closes#20271
To allow more flexibility and not be limited by defaults offered by
the runner machines:
- Visual Studio 2013: CMake 3.12.2
- Visual Studio 2015, 2017: CMake 3.16.2
Ref: https://www.appveyor.com/docs/windows-images-software/
Start using 3.18.4, 3.19.8, 3.20.6 in older VS jobs to add variations.
Time cost is a couple of seconds per job.
Ref: #18704 (Discussion)
Ref: #16973Closes#19737
It also means that all supported OpenSSL versions and forks support
TLSv1.3 after this patch.
It reduces `openssl.c` size by more than 10%, or 400 LOC.
Ref: #18822Closes#18330
- bump OpenSSL 3.4 to 3.5 on VS2022 runners.
- bump OpenSSL 1.1.1 to 3.0 on VS2019 runners.
1.1.1 is documented to be present, but missing.
Fixes:
```
+ cmake -G 'Visual Studio 16 2019' -A x64 [...] -DOPENSSL_ROOT_DIR=C:/OpenSSL-v111-Win64 [...]
CMake Error at C:/Program Files/CMake/share/cmake-4.1/Modules/FindPackageHandleStandardArgs.cmake:227 (message):
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY
OPENSSL_INCLUDE_DIR)
Call Stack (most recent call first):
CMakeLists.txt:757 (find_package)
```
Ref: https://ci.appveyor.com/project/curlorg/curl/builds/52740431/job/tq6h4xhqpa3vgq47?fullLog=true
Ref: https://www.appveyor.com/docs/windows-images-software/
Ref: 9a739f7bceCloses#18543
In CI we want to ensure that examples build cleanly, but we don't want
to actually run them there. Meaning it's enough to just compile, but not
link them in CI. Saving time up to 2-4x (MSVC), and disk space up
to 1.2GB (or 8-70x).
Add a new cmake target that compiles all examples without linking them
into runnable binaries. Keep a full build for a single example to test
if it links correctly.
Also:
- CI: switch over all `curl-examples` targets to `curl-examples-build`
- GHA/linux-old: build examples in one of the cmake builds.
Result highlights:
Job | Bef. | Bef. | Aft. | Aft. |
:------------------ | ---: | ----: | ---: |----: |
cygwin | 15s | 9MB | 10s | 1MB |
msys | 13s | 8MB | 7s | 1MB |
dl-mingw 15 | 39s | 113M | 34s | 2MB |
dl-mingw 9.5.0 | 49s | 115MB | 42s | 2MB |
dl-mingw 7.3.0 | 19s | 113MB | 14s | 2MB |
dl-mingw 6.4.0 | 9s | 12MB | 7s | 4MB |
Linux cross | 19s | 28MB | 19s | 2MB |
MSVC UWP | 65s | 374MB | 9s | 17MB |
MSVC x64 | 22s | 846MB | 9s | 17MB |
VS2010 | 48s | 105MB | 15s | 9MB |
VS2022 clang-cl | 195s | 1.2GB | 51s | 20MB |
iOS Xcode | 8s | | 5s | |
macOS LibreSSL | 16s | | 11s | |
Linux aws-lc | 3s | | 1s | |
Follow-up to dda251ef10#18232Closes#18209
It became flaky today, possible due to an upstream issue. Drop this CI job
also because VS2008 is going to be deprecated soon.
Example:
```
1>------ Build started: Project: curlu, Configuration: Debug Win32 ------
1>Compiling...
1>Project : error PRJ0003 : Error spawning 'cl.exe'.
1>Build log was saved at "file://c:\projects\curl\_bld\lib\curlu.dir\Debug\BuildLog.htm"
1>curlu - 1 error(s), 0 warning(s)
[...]
8>Linking...
8>LINK : fatal error LNK1104: cannot open file '..\..\lib\Debug\curlu-d.lib'
8>Build log was saved at "file://c:\projects\curl\_bld\tests\unit\units.dir\Debug\BuildLog.htm"
8>Test units - 1 error(s), 0 warning(s)
[...]
========== Build: 7 succeeded, 2 failed, 5 up-to-date, 0 skipped ==========
[...]
Command exited with code 1
```
Other times with no visible error all:
```
========== Build: 9 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========
[...]
Command exited with code 1
```
Ref: https://ci.appveyor.com/project/curlorg/curl/builds/52330703/job/ooqxq0b8ftbsv640#L413
Follow-up to 8c9a9b87c2#17725
Follow-up to 63e513b106#17380Closes#17798
Make test bundles the default. Drop non-bundle build mode.
Also do all the optimizations and tidy-ups this allows, simpler builds,
less bundle exceptions, streamlined build mechanics.
Also rework the init/deinit macro magic for unit tests. The new method
allows using unique init/deinit function names, and calling them with
arguments. This is in turn makes it possible to reduce the use of global
variables.
Note this drop existing build options `-DCURL_TEST_BUNDLES=` from cmake
and `--enable-test-bundles` / `--disable-test-bundles` from autotools.
Also:
- rename test entry functions to have unique names: `test_<testname>`
This removes the last exception that was handled in the generator.
- fix `make dist` to not miss test sources with test bundles enabled.
- sync and merge `tests/mk-bundle.pl` into `scripts/mk-unity.pl`.
- mk-unity.pl: add `--embed` option and use it when `CURL_CLANG_TIDY=ON`
to ensure that `clang-tidy` does not miss external test C sources.
(because `clang-tidy` ignores code that's #included.)
- tests/unit: drop no-op setup/stop functions.
- tests: reduce symbol scopes, global macros, other fixes and tidy-ups.
- tool1621: fix to run, also fix it to pass.
- sockfilt: fix Windows compiler warning in certain unity include order,
by explicitly including `warnless.h`.
Follow-up to 6897aeb105#17468Closes#17590
- appveyor: make a job target Windows XP.
- examples/block_ip: force this specific example to target Vista to make
it compile when building curl for Windows XP. Fixing:
```
docs\examples\block_ip.c(157): warning C4013: 'inet_pton' undefined; assuming extern returning int
docs\examples\block_ip.c(272): warning C4013: 'inet_ntop' undefined; assuming extern returning int
```
Ref: https://ci.appveyor.com/project/curlorg/curl/builds/52102142/job/2ajdluhc20r4gmmw#L530
Cherry-picked from #17413Closes#17415
In the cases observed throughout the last year, `handle64` run once per
test run, but with no action (match or task kill). It did not help with
flakiness and seems redundant.
runtests launched it (if present) in Cygwin/MSYS jobs too, where it
probably shouldn't have, because we have seen no flakiness there. In CI
the tool was present and launched in MSYS2 jobs, but not in Cygwin.
After this patch the "clearlocks" warning remain in the log. They are
consistently appearing once in every MSVC CI log, early in the tests:
```
test 3207 SKIPPED: curl lacks OpenSSL support
[...START-OF-TESTS...]
test 0003...[HTTP POST with auth and contents but with content-length set to 0]
--pd---e--- OK (3 out of 1596, remaining: 17:50, took 1.423s, duration: 00:02)
test 0007...[HTTP with cookie parser and header recording]
--pd--oe--- OK (7 out of 1596, remaining: 07:51, took 1.485s, duration: 00:02)
test 0006...[HTTP with simple cookie send]
--pd---e--- OK (6 out of 1596, remaining: 09:11, took 1.488s, duration: 00:02)
test 0005...[HTTP over proxy]
--pd---e--- OK (5 out of 1596, remaining: 11:03, took 1.491s, duration: 00:02)
CUSTOMBUILD : error : 169: cleardir(log/8/lock) failed [D:\a\curl\curl\bld\tests\test-ci.vcxproj]
test 0001...[HTTP GET]
--pd---e--- OK (1 out of 1596, remaining: 55:34, took 1.466s, duration: 00:02)
test 0004...[Replaced internal and added custom HTTP headers]
```
Ref: https://github.com/curl/curl/actions/runs/13546192228/job/37858323380?pr=16484#step:14:167
Ref: e53523fef0#14859
Ref: 311c31ec8e#6179
Follow-up to 3a8920e5ed#16600Closes#16484
Switch VS2008 job the oldest runner machine. It adds the oldest CMake to
the Windows mix, from 2018-11-30. Not a beauty, missing support for `-B`
and Unity, but it's a version curl supports. It's newer than Old Linux.
The previous oldest was 3.16.2. It remains used with VS2010-VS2017.
Also:
- fix VS2008 job to actually build examples.
- switch VS2019 job to OpenSSL 1.1.0 that wasn't tested before.
Migrate OpenSSL 1.0.2 to the VS2008 job.
- measure run time of individual build steps.
Follow-up to 01c25e3b00#16458Closes#16505
- appveyor: restore VS2008 job, after fixing its issues.
Enable OpenSSL in it. It takes 1 minute.
Follow-up to 9b0467b169#16453
Follow-up to edfa537100#16456
- appveyor: make a copy of OpenSSL DLLs to have them picked up as an
artifact (disabled by default) to aid local tests.
- appveyor: dump CMake configuration logs on failure.
- appveyor: tidy up job parameter defaults.
- GHA/windows: add pre-fill check option for dl-mingw jobs.
- GHA/windows: fix pre-fill check option for MSYS jobs by installing
`diffutils`.
Follow-up to e7adf3e837#15841
- GHA/windows: de-duplicate to `PATH` commands for Cygwin.
- GHA/windows: drop `$SYSTEMROOT/System32` from `PATH` for Cygwin
configure. It's not needed.
Follow-up to 36fd2dd6ee#13599
- list `.pdb` files in curl version step for MSVC.
Ref: #16439
Cherry-picked from #16394Closes#16458
Static CRT crashes MSVCR* MSVC builds (in VS2008, VS2010, VS2012,
VS2013) according to CI and local tests. The reproducible crash happens
in `curl_mfprintf() -> fputc(s, stderr)` when trying to display the
warning message in `curl -V`. `stderr` is non-NULL and resolves to `2`.
This reproducer needs a debug-enabled build, but it's unrelated to debug
features or curl's memory tracker. It happens regardless of unity build,
CPU architecture or `DllMain()` use. Example from VS2013:
```
+ _bld/src/Debug/curl.exe --disable --version
./appveyor.sh: line 124: 203 Segmentation fault "${curl}" --disable --version
```
Ref: https://ci.appveyor.com/project/curlorg/curl/builds/51570451/job/ojpdqrsm1hmpmq6a#L210
Another crash happened in an UCRT build (VS2017) with a couple of
`printf()`s added to curl's `main()` function:
```
Microsoft Visual C++ Runtime Library
Debug Assertion Failed!
Program: C:/projects/curl/bld/src/Debug/curl.exe
File: minkernel/crts/ucrt/src/appcrt/heap/debug_heap.cpp
Line: 996
Expression: _act_first_block == header
```
(it hangs the job in CI due to the GUI popup)
Ref: https://github.com/curl/curl/pull/16394#issuecomment-2677181716
To avoid actual and potential issues, this patch issues a warning on
the shared-libcurl + static-CRT combination and falls back to the
default, shared CRT. IOW a static CRT build now requires a static curl
exe when using the `CURL_STATIC_CRT=ON` option.
Follow-up to 4fc6ebe18a#1621
Cherry-picked from #16394 (with more details there)
Closes#16456
Support multi-target cmake builds via `CURL_DIRSUFFIX` env. For example:
`export CURL_DIRSUFFIX=Debug/`.
Multi-target generators place their output to `src/<subdir>/`,
`lib/<subdir>/`, `tests/server/<subdir>`, `tests/libtest/<subdir>` and
`tests/unit/<subdir>/` by default. Before this patch, `runtests.pl`
couldn't run on such builds because it expected the binaries under the
their `<subdir>`-less directories. This patch allows to set such subdir
and make `runtests.pl` find the binaries. In CI we use multi-target
builds with tests for MSVC. It also helps Xcode-generator builds, though
in CI we don't have such job running tests.
There may be better solutions to configure this, but passing a custom
value to `runtests.pl` including its subprocesses is somewhat tricky.
The reason the configuration value expects the slash at the end is
because MSYS is automagically expanding the env to a (wrong) absolute
path if the slash is in the front.
Also:
- drop the `-DCMAKE_RUNTIME_OUTPUT_DIRECTORY_*=` workaround from CI.
- replace `resolve` references in tests with a new `%RESOLVE` variable.
It didn't use a filename extension before. After this patch it uses
`exe_ext('TOOL')`. I'm not sure if this is the correct choice vs.
`exe_ext('SRV')`.
- fix `-c` option format in manual.
- fix some whitespace.
Note, in CI we still tweak `CMAKE_RUNTIME_OUTPUT_DIRECTORY_*` in jobs
which share steps between `./configure` and cmake. It's easier that way.
Ref: #15000
Cherry-picked from #16394Closes#16452
They use Visual Studio generators, which are multi-target.
The build command does the Release/Debug selection via `--config`.
Also:
- appveyor: drop unnecessary conditional for 3 options.
To sync with GHA.
- appveyor: drop unused `-DCMAKE_INSTALL_PREFIX=`.
To sync with GHA.
- sync cmake option order between GHA and appveyor.
Closes#16372
- replace `add_compile_options()`, `add_definitions()` with directory
properties. To harmonize this across all scripts. The new commands are
verbose, but describe better how they work. The syntax is also closer
to setting target properties, helps grepping.
- prefer `CMAKE_INSTALL_PREFIX` over `--prefix` (in tests, CI).
- tidy up cmake invocations.
- formatting.
Closes#16238
TL;DR: Save 10 minutes of CI time for GHA/macos jobs using pre-fills and
add pre-fill verification for Apple and Windows. Also restores Xcode job
and saves 1.5-10 minutes configuring iOS jobs.
Pre-filling feature detection results can bring down the CMake configure
step to ~5 seconds on most GHA runners, ~10 seconds in slow envs like
Cygwin/MSYS2.
The potential savings per job are:
- 5-40 (average 19) seconds on GHA/macos (33 jobs)
- ~10 seconds on GHA for iOS GNU Makefile (1 job)
- 1.5-10 minutes on GHA for iOS Xcode generator (1 job)
- 10 seconds on GHA/linux with native Ubuntu (12 jobs)
- 40 seconds for Cygwin/MSYS2 (2 jobs)
- 5-10 seconds for virtualized BSDs, native CPU (3 jobs)
- ~60 seconds for virtualized BSDs, emulated CPU (1 job)
On native Windows pre-filling has been in place for a long time and
saving 8 minutes (VS2019-VS2015) to 1.5-2 minutes (VS2022), 3 minutes
(VS2022 UWP), and 30-60 seconds (MinGW), per CI job.
The downside is that detection results need to be manually collected and
filtered to those that universally apply to all platforms that they are
enabled on. Another downside is that by using a cache, we're not running
the actual detections, and thus won't catch regressions in them. It
means we must make sure that the cache is solid and matches with actual
detections results. An upside is that it gives a rough overview of which
features are available on which platforms. Another upside is pre-filled
values do work for feature detections skipped for cross-builds, e.g.
`HAVE_WRITABLE_ARGV`.
This PR adds a pre-fill cache that supports all Unixes (except OmniOS)
used in CI, and makes it usable with an internal option. It also enables
it for GHA/macos CI jobs, where the maximum savings are. And also for
the two iOS [1] and two Cygwin/MSYS2 jobs. The latters don't have
pre-fill checks and we can drop them if they turn into a hassle.
Saving:
- 10 minutes of CI time per GHA/macos workflow run. [2]
- ~80 seconds per GHA/windows workflow run with Cygwin/MSYS2.
(offsetting the cost of pre-fill verifications)
- 1.5-10 minutes per GHA/non-native runs with iOS jobs. [3]
You can enable pre-fill locally with `-D_CURL_PREFILL=ON`. It's
experimental, and if you experience a problem, file a PR or an Issue.
This PR also adds a pre-fill checker for macOS and MinGW/MSVC Windows
GHA jobs to catch if the cache diverges from real detections. It also
adds this logic to AppVeyor, but doesn't enable it due to the perf
penalty of 2 minutes mininum.
The pre-fill checker works by configuring out-of-tree with and without
pre-fill, then diffing their `lib/curl_config.h` outputs.
Exceptions are 3 detection results exposed indirectly [4], and missing
to expose 2, of which one is the C89 header `stddef.h`. While we assume
the C99 `stdint.h` available outside iOS. We can expose them in the
future, if necessary.
The pre-fill checks cost in total:
- ~20 seconds for macOS
- ~40 seconds for MinGW on GHA
- ~80 seconds for MSVC on GHA (UWP would be 2x this)
An extra time saving potential is caching type sizes. They are
well-known, and seldom change, esp. in CI. GHA/Windows jobs spend 8-17
seconds per job on these ~12 feature checks. ~5s on Cygwin/MSYS2. Couple
of seconds on other platforms. (This PR doesn't make this optimization.)
Another opportunity is doing the same for autotools, which typically
spends more time in the configuration step than cmake.
[1] Xcode job restored as a
follow-up to be5f20202c#16302
[2] GHA/macos cmake configure times in seconds:
Job | Bef. | After | Gain
:----------------------------------------------- | ----: | ----: | ----:
CM clang GnuTLS !ldap krb5 | 21.2 | 4.5 | 16.7
CM clang LibreSSL !ldap heimdal c-ares +examples | 13.3 | 3.9 | 9.4
CM clang OpenSSL +static libssh +examples | 20.0 | 4.6 | 15.4
CM clang OpenSSL IDN clang-tidy~ (w/chkprefill) | 15.7 | 18.6 | -2.9
CM clang OpenSSL gsasl rtmp AppleIDN | 25.0 | 4.7 | 20.3
CM clang OpenSSL torture !FTP | 15.3 | 4.5 | 10.8
CM clang OpenSSL torture FTP | 25.0 | 5.9 | 19.1
CM clang SecureTransport debug | 18.0 | 3.8 | 14.2
CM clang macos-13 SecureTransport | 45.8 | 12.4 | 33.4
CM clang macos-14 SecureTransport | 15.8 | 4.6 | 11.2
CM clang macos-15 SecureTransport | 26.8 | 6.1 | 20.7
CM clang mbedTLS openldap brotli zstd | 15.1 | 6.5 | 8.6
CM clang wolfSSL !ldap brotli zstd | 27.0 | 4.4 | 22.6
CM gcc-12 GnuTLS !ldap krb5 | 39.1 | 8.7 | 30.4
CM gcc-12 LibreSSL !ldap heimdal c-ares +examples| 23.8 | 7.2 | 16.6
CM gcc-12 OpenSSL +static libssh +examples | 20.7 | 8.5 | 12.2
CM gcc-12 OpenSSL gsasl rtmp AppleIDN | 23.1 | 10.1 | 13.0
CM gcc-12 SecureTransport debug | 21.1 | 4.8 | 16.3
CM gcc-12 mbedTLS openldap brotli zstd | 21.4 | 5.8 | 15.6
CM gcc-12 wolfSSL !ldap brotli zstd | 21.1 | 6.9 | 14.2
CM gcc-14 macos-13 SecureTransport | 61.9 | 18.7 | 43.2
CM gcc-14 macos-14 SecureTransport | 30.5 | 6.4 | 24.1
CM gcc-14 macos-15 SecureTransport | 32.7 | 8.4 | 24.3
CM llvm@15 GnuTLS !ldap krb5 | 21.1 | 7.5 | 13.6
CM llvm@15 LibreSSL !ldap heimdal c-ares +exampl~| 24.6 | 6.8 | 17.8
CM llvm@15 OpenSSL +static libssh +examples | 19.0 | 6.4 | 12.6
CM llvm@15 OpenSSL gsasl rtmp AppleIDN | 19.0 | 8.2 | 10.8
CM llvm@15 SecureTransport debug | 18.0 | 5.4 | 12.6
CM llvm@15 macos-13 SecureTransport | 66.2 | 25.7 | 40.5
CM llvm@15 macos-14 SecureTransport | 31.9 | 6.1 | 25.8
CM llvm@15 mbedTLS openldap brotli zstd | 19.5 | 8.9 | 10.6
CM llvm@15 wolfSSL !ldap brotli zstd | 24.3 | 5.9 | 18.4
CM llvm@18 macos-15 SecureTransport | 33.8 | 6.4 | 27.4
Total | 856.8 | 257.3 | 599.5
Before: https://github.com/curl/curl/actions/runs/13311042735/job/37173478424
After: https://github.com/curl/curl/actions/runs/13313927119/job/37183206426?pr=15841
[3] iOS:
Before: https://github.com/curl/curl/actions/runs/13326401704?pr=15841
After: https://github.com/curl/curl/actions/runs/13332177764?pr=15841
[4] detection results exposed indirectly in `curl_config.h`:
- `HAVE_FILE_OFFSET_BITS` via `_FILE_OFFSET_BITS`
- `HAVE_GETHOSTBYNAME_R_*_REENTRANT` via `NEED_REENTRANT`
- `HAVE_SOCKADDR_IN6_SIN6_ADDR` via `USE_IPV6`
Closes#15841
- add VS2019 job, with Schannel + OpenSSL 1.0.2.
First MultiSSL job here and add the last missing modern VS version.
- fix builds with mixed ALPN capabilities in MultiSSL unity builds.
Caused by reusing `HAS_ALPN` between TLS modules without
resetting it. Fix it by using unique names for each backend.
- merge a VS2010 job into a VS2012. With MultiSSL and x86 OpenSSL.
- make a job static.
- fix `Shared`/`Static` in a job name.
- add `Shared` to job names.
Closes#16231
Rework the way `tool_hugehelp.c` is included in builds.
After this patch, with `./configure` and CMake `tool_hugehelp.c` is only
compiled when building with manuals enabled. With manuals disabled this
source file is not used anymore. The method is similar to how
8a3740bc8e implemented `tool_ca_embed.c`.
`./configure` always generates it as before, otherwise the build fails.
- winbuild: rework to not need `buildconf.bat`, but automatically use
`tool_hugehelp.c` if present (e.g. when building from an official
source tarball) and enable `USE_MANUAL` accordingly.
- `buildconf.bat`: after dropping `tool_hugehelp.c` generation, the only
logic left was `cp Makefile.dist Makefile`. This allowed to launch
winbuild builds via GNU Make in a Git repo. Drop this option together
with the batch file.
- build `libcurltool` without `USE_MANUAL` macro to exclude the manual
and the dependence on the generator commands. Drop relying on
`UNITTESTS` for this purpose.
Follow-up to 96843f4ef7#16068
- `src/mkhelp.pl`: include `tool_hugehelp.h` before using `USE_MANUAL`
to have it set in `config-*.h` builds with source tarballs created
with manual but without zlib.
Closes#16081
- fix `find` commands to not miss items.
- call `file` on the built files in `curl -V` steps.
To give more feedback on what was built.
- add `curl info` step for cross-jobs that can't do a `curl -V`.
It lists the files built and calls `file` on them.
- appveyor: make a VS2010 32-bit to match the VS2008 job it replaced.
Follow-up to d34aeecb08#15934
- GHA/windows: drop the word "old" from standalone mingw-w64 jobs to not
conflate it with "old mingw" we no longer support (while also keeping
it short).
Cherry-picked from #15975Closes#16001
We recommend migrating to CMake from winbuild and Visual Studio project
files. winbuild is deprecated and will be dropped in September 2025.
CMake supports all the features and options, with new ones added
promptly. It supports out-of-tree, unity and documentation builds.
- deprecate winbuild method in favour of CMake by September 2025.
- add migration guide from winbuild to CMake.
- add migration guide from Visual Studio Project Files to CMake.
- add deprecation message to winbuild.
Need to ack with `WINBUILD_ACKNOWLEDGE_DEPRECATED=yes`
Authored-by: Jay Satiro
- mention `CMAKE_BUILD_TYPE` option in `INSTALL-CMAKE`.
- document missing `SSH_PATH` winbuild option.
Closes#15920
VS2008 has been partly broken for a while with its shared-debug builds
crashing on startup. Its compiler output (UTF-16 HTML) was also barely
readable even after conversion. It's also the only platform in CI
missing `stdint.h`.
This patch migrates a VS2008 job to VS2010 and drops another that
already had a VS2010 equivalent.
We recommend switching to VS2010 or newer when using MSVC to build curl.
Ref: #15907Closes#15934
- appveyor: add build-only job for clang-cl.
- cmake: `-pedantic-errors` enables `-Werror,-Wlanguage-extension-token`
automatically, which makes `__int64` detection fail.
Explictly disable this compiler warning for clang-cl to make the
feature detection work and to accept `__int64` in the source code.
- cmake: disable `-Wlanguage-extension-token` warning for clang-cl
to fix these when encountering `__int64`:
```
lib/formdata.c(797,29): error : extension used [-Werror,-Wlanguage-extension-token]
lib/warnless.c(117,33): error : extension used [-Werror,-Wlanguage-extension-token]
lib/warnless.c(60,28): message : expanded from macro 'CURL_MASK_SCOFFT'
lib/warnless.c(59,38): message : expanded from macro 'CURL_MASK_UCOFFT'
include\curl/system.h(352,40): message : expanded from macro 'CURL_TYPEOF_CURL_OFF_T'
```
- make `__GNUC__` warning suppressions apply to `__clang__` too.
Necessary for clang-cl, which defines the latter, but not the former.
(Regular clang defines both.)
- examples: fix clang-cl compiler warning in `http2-upload.c`.
```
docs\examples\http2-upload.c(56,5): error : no previous prototype for function 'my_gettimeofday' [-Werror,-Wmissing-prototypes]
docs\examples\http2-upload.c(56,1): message : declare 'static' if the function is not intended to be used outside of this translation unit
```
- unit2604: add missing `#pragma GCC diagnostic pop`.
Follow-up to e53523fef0#14859
- unit1652: limit compiler warning suppression to GCC.
They do not affect clang builds.
Follow-up to 71cf0d1fca#14772Closes#15449
- Move `docs/examples` builds under a separate target.
- Make `BUILD_EXAMPLES` default to `ON`. It means to generate the rules
for `docs/examples` by default, but not build them. To build them,
an explicit `make curl-examples` (or ninja, etc) command is necessary.
This syncs behaviour with autotools, and also how both cmake and
autotools are building tests.
- GHA: update cmake jobs to use the new way of building examples.
- GHA: move examples build step at the end of the job, after building
and running tests. This allows to have build and test run results
faster, and leave the seldom-changing examples build to the end.
Building examples is the slowest build step with no practical way to
make them fast.
- appveyor: enable building examples in two old-MSVC jobs.
- examples: fix examples to build cleanly with old MSVC versions.
- GHA/non-native: move example build log under a GHA foldable section.
- GHA/windows: move building examples into separate step for Linux cross
jobs.
Follow-up to dfdd978f7c#13491Closes#14906
Also:
- explicitly disable libpsl in CI to avoid configure warning, where
necessary.
- add TODO to make this warning an error (to match autotools.)
Follow-up to 2998874bb6#12661Closes#14533
The test-ci target now uses 2 processes by default, but the amount of
parallelism is tuned for each CI service and build environment based on
results of a number of test runs. Some CI services use super-
oversubscribed build machines that can barely run the curl tests
already with no parallelism without frequently failing with
timing-induced failures. These continue to be run without parallelism.
Other services provide two fast, unloaded cores and these run with 14
processes, which is a good default for this kind of environment.
Here's a summary of the number of test processes by CI service:
Appveyor - 2 (Windows MSVC), 1 (others)
Azure - 2
Circle CI - 14
Cirrus - 28 (macOS), 14 (Linux), 7 (FreeBSD), 5 (macOS torture), 2 (Windows)
GitHub Actions - 3 (macOS), 2 (Linux)
Some of these are a bit conservative to keep timing-induced flakiness down.
The net result is that the first test results should arrive only
3 minutes after a commit submission.
Changes merged via separate commits:
- 2a7c8b27fd#14171
- 72341068a2
- efce544418#14244
- c6cf411bac
Ref: #10818Closes#11510
This seems to be the only way to see what actual toolchain commands were
run, and with what arguments.
Without `dos2unix`, `cat` output comes out empty.
Closes#13957
Simplify controlling whether to build and/run tests in a CI job.
Apply the TFLAGS='skipall' (do not build nor run tests) or
'skiprun' (build, but do not run) method already used with old-mingw-w64
and msvc jobs to existing Windows jobs in GHA and AppVeyor.
Also:
- add Cygwin/cmake test build and run steps while here.
- replace `DISABLED_TESTS` with `TFLAGS` in AppVeyor.
Closes#13796
Before this patch, `ENABLE_CURLDEBUG` (memory tracking) was
unconditionally enabled when `ENABLE_DEBUGBUILD` was set. This made
testing some build configurations complicated. To fix it, this patch
makes `ENABLE_CURLDEBUG` to receive the value of `ENABLE_DEBUG` by
default, while allowing free override by the user.
This allows to use the config:
`ENABLE_DEBUGBUILD=ON ENABLE_CURLDEBUG=OFF`
to enable debug features, without also enabling memory tracking.
This is important because some other build methods allow to set one of
these features but not the other. This patch allows to test any
combination with CMake.
This makes it unnecessary to use the workaround of passing
`-DDEBUGBUILD` via `CMAKE_C_FLAGS`. Which has the disadvantage that our
CMake logic cannot easily detect it, e.g. for disabling symbol hiding on
Windows for `ENABLE_DEBUG`/`DEBUGBUILD` builds.
Cherry-picked from #13718Closes#13792
Before this patch `ENABLE_DEBUG=ON` always enabled the TrackMemory
(aka `ENABLE_CURLDEBUG=ON`) feature, but required the `Debug` CMake
configration to actually enable curl debug features
(aka `-DDEBUGBUILD`).
Curl debug features do not require compiling with C debug options. This
also made enabling debug features unintuitive and complicated to use.
Due to other issues (subject to PR #13694) it also caused an error in
default (and `Release`/`MinSizeRel`/`RelWithDebInfo`) configs, when
building the `testdeps` target:
```
ld: CMakeFiles/unit1395.dir/unit1395.c.o: in function `test':
unit1395.c:(.text+0x1a0): undefined reference to `dedotdotify'
```
Ref: https://github.com/curl/curl/actions/runs/9037287098/job/24835990826#step:3:2483
Fix it by always defining `DEBUGBUILD` when setting `ENABLE_DEBUG=ON`.
Decoupling this option from the selected CMake configuration.
Note that after this patch `ENABLE_DEBUG=ON` unconditionally enables
curl debug features. These features are insecure and unsuited for
production. Make sure to omit this option when building for production
in default, `Release` (and other not-`Debug`) modes.
Also delete a workaround no longer necessary in GHA CI jobs.
Ref: 1a62b6e68c (2015-03-03)
Ref: #13583Closes#13592
