mirror of
https://github.com/open-goal/jak-project
synced 2026-09-12 12:55:22 -04:00
Alexander J. Semenuk
5d5e35fb9b
## Problem Windows builds break with a current local toolchain (Scoop LLVM 22.1.8, CMake 4.4.0, VS 2026), in two independent ways: 1. The build stops at curl's deliberate guard: `#error "no non-blocking method was found/used/set"` in `third-party/curl/lib/nonblock.c`. 2. From the second configure onward, `cmake --build` re-runs CMake in an endless loop (observed 42 consecutive reconfigure cycles in a single build). Likely the same mechanism behind the "endlessly building" VS 2026 note in `docs/setup/dev/vs.md`. ## Root cause 1. `third-party/curl/CMake/CurlTests.c` passes `int *` to `ioctlsocket()`, whose third parameter is `u_long *`. Clang 22 promotes `-Wincompatible-pointer-types` to a hard error in C, so the `HAVE_IOCTLSOCKET_FIONBIO` try_compile silently fails and `curl_config.h` never defines it. Upstream CI does not see this because the windows-2022 runner image ships an older LLVM. GCC 14 promotes the same warning to a hard error, which is very likely the `CurlTests.c.obj` failure reported from MSYS2 in open-goal/jak-project#3551. Upstream curl hit the identical problem with GCC 14 and fixed the probe in curl 8.8.0 (curl/curl#13578). 2. The root CMakeLists copies the build tree's `compile_commands.json` into `<src>/build/` for clangd using `configure_file()`, which registers its input as a configure dependency. CMake rewrites `compile_commands.json` late in every generation, after `CTestTestfile.cmake` and `cmake_install.cmake` (outputs of the same Ninja regen rule), so once the dependency is registered the rule is deterministically dirty and every `ninja` invocation re-runs CMake. A pristine first configure is safe (the file does not exist yet, so the `if(EXISTS ...)` guard skips the copy), which is why the loop looks machine- or IDE-specific. ## Fix 1. Per review, re-vendor `third-party/curl` at the `curl-8_21_0` tag (previously `curl-8_3_0`), which carries the upstream probe fix plus two years of upstream development; `vendor.yaml` updated to match. Adjustments the version jump forced: - curl 8.15 removed the native macOS Secure Transport backend (`CURL_USE_SECTRANSP`), so macOS now builds curl against OpenSSL like Linux. The two macOS workflows install Homebrew `openssl@3` and export `OPENSSL_ROOT_DIR` (keg-only), and the macOS setup docs gained the same two lines. - `CURL_BROTLI` / `CURL_ZSTD` switched to AUTO-detection in curl 8.10; pinned OFF to keep the previous no-compression behavior and avoid silently linking whatever the CI images happen to have. - curl's new top-level `BUILD_EXAMPLES` cache option (default ON) leaked into discord-rpc's identically named option and broke configure at a nonexistent `examples/send-presence` directory; pinned OFF ahead of the third-party subdirectories. The diff is dominated by the mechanical tag-tree swap under `third-party/curl` (linguist-vendored, collapsed in review). The hand-written changes are `CMakeLists.txt`, the two macOS workflows, `docs/setup/system/macos.md`, and `vendor.yaml`. 2. Swap `configure_file()` for `file(COPY ...)`: the same clangd copy with no configure dependency registered. (`file(COPY_FILE ... ONLY_IF_DIFFERENT)` would be cleaner still but requires CMake 3.21, above the declared `cmake_minimum_required(VERSION 3.10)`.) ## Test plan - [x] Fresh `cmake --preset Release-windows-clang` (LLVM 22, no cache seeding) completes and logs `Enabled SSL backends: Schannel`; the FIONBIO probe passes without the previous `#error` - [x] Full Windows Release build from scratch in the branch worktree (all 1422 targets) - [x] goalc-test suite: 1509 passed, 0 failed - [x] Second consecutive configure with `compile_commands.json` present: the regen rule in `build.ninja` has no `compile_commands.json` input; `<src>/build/compile_commands.json` is still refreshed for clangd - [x] Repeated `ninja` invocations after a full build no longer re-run CMake - [x] macOS Intel and ARM CI green (first exercise of the OpenSSL backend switch) --- I work off a self-hosted forge, so this GitHub account is quiet; the configure logs and ninja dirty-node traces from the investigation are available if anyone wants the raw data. (AI-assisted)
112 lines
3.4 KiB
Markdown
Vendored
Generated
112 lines
3.4 KiB
Markdown
Vendored
Generated
<!--
|
|
Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
|
|
|
SPDX-License-Identifier: curl
|
|
-->
|
|
|
|
# `splay`
|
|
|
|
#include "splay.h"
|
|
|
|
This is an internal module for splay tree management. A splay tree is a binary
|
|
search tree with the additional property that recently accessed elements are
|
|
quick to access again. A self-balancing tree.
|
|
|
|
Nodes are added to the tree, they are accessed and removed from the tree and
|
|
it automatically rebalances itself in each operation.
|
|
|
|
## libcurl use
|
|
|
|
libcurl adds fixed timeout expiry timestamps to the splay tree, and is meant
|
|
to scale up to holding a huge amount of pending timeouts with decent
|
|
performance.
|
|
|
|
The splay tree is used to:
|
|
|
|
1. figure out the next timeout expiry value closest in time
|
|
2. iterate over timeouts that already have expired
|
|
|
|
This splay tree rebalances itself based on the time value.
|
|
|
|
Each node in the splay tree points to a `struct Curl_easy`. Each `Curl_easy`
|
|
struct is represented only once in the tree. To still allow each easy handle
|
|
to have a large number of timeouts per handle, each handle has a sorted linked
|
|
list of pending timeouts. Only the handle's timeout that is closest to expire
|
|
is the timestamp used for the splay tree node.
|
|
|
|
When a specific easy handle's timeout expires, the node gets removed from the
|
|
splay tree and from the handle's linked list of timeouts. The next timeout for
|
|
that handle is then first in line and becomes the new timeout value as the
|
|
node is re-added to the splay.
|
|
|
|
## `Curl_splay`
|
|
|
|
~~~c
|
|
struct Curl_tree *Curl_splay(struct curltime i, struct Curl_tree *t);
|
|
~~~
|
|
|
|
Rearranges the tree `t` after the provide time `i`.
|
|
|
|
## `Curl_splayinsert`
|
|
|
|
~~~c
|
|
struct Curl_tree *Curl_splayinsert(struct curltime key,
|
|
struct Curl_tree *t,
|
|
struct Curl_tree *node);
|
|
~~~
|
|
|
|
This function inserts a new `node` in the tree, using the given `key`
|
|
timestamp. The `node` struct has a field called `->payload` that can be set to
|
|
point to anything. libcurl sets this to the `struct Curl_easy` handle that is
|
|
associated with the timeout value set in `key`.
|
|
|
|
The splay insert function does not allocate any memory, it assumes the caller
|
|
has that arranged.
|
|
|
|
It returns a pointer to the new tree root.
|
|
|
|
## `Curl_splaygetbest`
|
|
|
|
~~~c
|
|
struct Curl_tree *Curl_splaygetbest(struct curltime key,
|
|
struct Curl_tree *tree,
|
|
struct Curl_tree **removed);
|
|
~~~
|
|
|
|
If there is a node in the `tree` that has a time value that is less than the
|
|
provided `key`, this function removes that node from the tree and provides it
|
|
in the `*removed` pointer (or NULL if there was no match).
|
|
|
|
It returns a pointer to the new tree root.
|
|
|
|
## `Curl_splayremove`
|
|
|
|
~~~c
|
|
int Curl_splayremove(struct Curl_tree *tree,
|
|
struct Curl_tree *node,
|
|
struct Curl_tree **newroot);
|
|
~~~
|
|
|
|
Removes a given `node` from a splay `tree`, and returns the `newroot`
|
|
identifying the new tree root.
|
|
|
|
Note that a clean tree without any nodes present implies a NULL pointer.
|
|
|
|
## `Curl_splayset`
|
|
|
|
~~~c
|
|
void Curl_splayset(struct Curl_tree *node, void *payload);
|
|
~~~
|
|
|
|
Set a custom pointer to be stored in the splay node. This pointer is not used
|
|
by the splay code itself and can be retrieved again with `Curl_splayget`.
|
|
|
|
## `Curl_splayget`
|
|
|
|
~~~c
|
|
void *Curl_splayget(struct Curl_tree *node);
|
|
~~~
|
|
|
|
Get the custom pointer from the splay node that was previously set with
|
|
`Curl_splayset`. If no pointer was set before, it returns NULL.
|