[siracozmen01]

Problem

The engine pins Maul UI 1.3.2 and Maul Unicode 1.0.0. Maul UI 1.3.3 and Maul Unicode 1.1.2 are released and verified.

Change

• third_party/maul-ui is Maul UI 1.3.3, and third_party/maul-unicode is Maul Unicode 1.1.2. Each was vendored with tools/update_maul.sh, which checked the archive against its release's SHA256SUMS. Each archive also has one attestation on GitHub, and each tag is the commit docs/operations/dependencies.md now gives.
• Pins:
  • Maul UI 1.3.3's cmake/*.cmake names the same Window (0.12.0), Unicode (1.0.0), Tween (1.0.0), RHI (0.15.0), FreeType (2.14.3) and HarfBuzz (14.5.1) releases as 1.3.2, so those pins stay.
  • Unicode moves past what UI and Window name, to 1.1.2. Maul Unicode 1.x promises no breaking release within 1.x, and its CMake package takes a request for any earlier 1.y. How the engine builds them on it is below.
  • Maul Window 0.13.0 is out, but no Maul UI release names it yet, so Window stays at 0.12.0.
• How UI and Window take Unicode 1.1.2 here, with no version check skipped or patched:
  • third_party/maul_ui.cmake sets FETCHCONTENT_FULLY_DISCONNECTED and FETCHCONTENT_SOURCE_DIR_MAUL-UNICODE to third_party/maul-unicode. Maul UI's text component (cmake/TextDependencies.cmake) declares maul-unicode at its pinned tag, and FetchContent configures it from that directory. Maul UI comes first, so it makes the one maul-unicode target.
  • Maul Window's find_package(maul-unicode 1.0.0 CONFIG QUIET) finds no installed package. Its FetchContent_Declare(maul-unicode ...) of the same name then takes the target already made. FetchContent does not compare an override directory with the declared tag, so no check in either library reads the vendored source's version.
  • The check that compares the two pins with VERSION_EQUAL, Maul UI's cmake/Window.cmake, belongs to maul-ui-window, the glue to Maul Window. It is included only with MAUL_UI_WINDOW, which is off by default, and third_party/maul_ui.cmake does not turn it on, since the engine drives Maul Window itself. So it never runs in the engine's build, with Unicode 1.0.0 or 1.1.2.
  • Both libraries therefore compile and link against 1.1.2, which is newer than what their own tests ran with. Maul Unicode's 1.x promise is what this rests on. If that is not enough, the alternative is to keep Unicode at 1.0.0 until Maul UI and Maul Window release on 1.1.
• No engine call site changes. The engine calls no Maul Unicode function itself: only Maul UI and Maul Window do.

What users see change

Every entry of the notes, with who sees it:

• Maul UI 1.3.3, #374: MUI_NODISCARD was empty under GCC 14 in C23 mode, and is now [[nodiscard]] there too. This changes only what a C program built with GCC 14 is warned about. The engine calls Maul UI from C++, where the attribute already held. Maul UI's own C sources build in the gcc-debug tree with GCC 14, and that tree built with no new warning.
• Maul Unicode 1.1.2, #276: every internal function that returns bool carries MUNI_NODISCARD. No call dropped one, so no behavior changes.
• Maul Unicode 1.1.1, #271: the same as UI's #374, for MUNI_NODISCARD. Maul UI's and Maul Window's C sources, which call Maul Unicode, built with GCC 14 in gcc-debug with no new warning.
• Maul Unicode 1.1.0, #264 and #267:
  • Every call that takes a segment or script iterator back now refuses one no init call set up. Maul UI and Maul Window set up every iterator they pass, so no result changes.
  • The check costs each iterator call a few nanoseconds: line breaking over English prose takes 1 to 2% longer. That reaches the engine's text layout through Maul UI. No results change, since Maul Unicode's data is still Unicode 18.0.0 and MUNI_RESULTS_VERSION stays 2.

Layouts, styles, draw lists, line breaks, shaped text, glyph images, motion curves and the accessibility tree are 1.3.2's, as Maul UI's notes say. No wire, save, checkpoint or cooked format changes, so the title has no !.

Verification

With Unicode 1.1.1, tools/check.sh full passed at four jobs through the heavy-job wrapper, in 1926 s:

• clang-thread: 208 of 208.
• clang-sanitize: 253 of 253.
• gcc-debug (GCC 14): 208 of 208.
• clang-development: 208 of 208 unit tests and 19 of 19 integration tests.
• wasm-development: 62 of 62.
• The web page, its shaders and its play of the runners and the plaza passed in the browser.

GCC 14 warnings: in gcc-debug, Maul UI, Maul Unicode (with its HarfBuzz functions), Maul Window and Maul Tween were cleaned and rebuilt alone with Unicode 1.1.1. All 336 C objects built with no warning.

With Unicode 1.1.2, Maul Unicode and its HarfBuzz functions were cleaned and rebuilt alone in gcc-debug: 87 C objects, no warning. Then tools/check.sh full passed again, in 1288 s:

• clang-thread: 208 of 208.
• clang-sanitize: 253 of 253.
• gcc-debug (GCC 14): 208 of 208.
• clang-development: 208 of 208 unit tests and 19 of 19 integration tests.
• wasm-development: 62 of 62.
• The web page, its shaders and its play of the runners and the plaza passed in the browser.

That run builds Maul UI and Maul Window against Unicode 1.1.2 inside the engine and runs every test above on them, which tests exactly this combination.

[siracozmen01]

Review at 59e6f85: changes needed (1). Read, not run.

1. docs/operations/dependencies.md still says the four move to the releases Maul UI names. Line 70 reads: "Each names the one release of the others it was built against ... So the four move to the releases Maul UI names, with Maul RHI at the one it names too."

• After this PR that is no longer true. Maul UI 1.3.3 names Maul Unicode 1.0.0, and the engine vendors 1.1.2.
• The body explains why that is sound: Maul Unicode's 1.x promise, the FetchContent override of both libraries' maul-unicode, and the glue's VERSION_EQUAL check living only in the off-by-default MAUL_UI_WINDOW. None of that is in the operations doc, which is what the next update follows.
• Please change the paragraph to say what the build now does: Maul Unicode may be newer, within 1.x, than the release Maul UI and Maul Window name; how the override hands both the vendored one; and that the glue's equality check is not part of the engine's build.

The rest holds.

• Vendored bytes. The files I fetched match their release tags byte for byte: src/segment.c and include/maul-unicode/base.h against maul-unicode v1.1.2, and include/maul-ui/base.h against maul-ui v1.3.3.
• I cannot compare whole trees from here. Please run diff -r of third_party/maul-unicode and third_party/maul-ui against the extracted maul-unicode-1.1.2.tar.gz and maul-ui-1.3.3.tar.gz, limited to the paths the rows list, as for #212.
• Pins and rows. The rows name Maul Unicode 1.1.2 at b026e91 (v1.1.2) and Maul UI 1.3.3 at 713c044 (v1.3.3), each with its archive's SHA-256. b026e91 is the v1.1.2 commit that maul-window #482 compared against. Please confirm 713c044 is the v1.3.3 tag's commit.
• Results. None of the listed entries changes a result the engine reaches.
  • UI's #374 and Unicode's #271 and #276 are compile-time attributes.
  • Unicode's #264 and #267 refuse only iterators no init call set up, and Maul UI and Maul Window pass only initialized ones, copies included. So the only effect is the 1 to 2% cost on line breaking.
  • Each release keeps the data at 18.0.0 and MUNI_RESULTS_VERSION at 2.
  • The engine calls no Maul Unicode function itself.
• So no ! is right, and nothing in the engine's own code needs to change.

[siracozmen01]

Delta review, 59e6f85 to a6dc372: ready. Read, not run.

The delta is the one paragraph of docs/operations/dependencies.md. It now says what the build does:

• Maul Window, Maul Tween and Maul RHI follow the releases Maul UI names.
• Maul Unicode may be a later release within its major version: no breaking release within 1.x, and its package takes any earlier 1.y.
• third_party/maul_ui.cmake points FetchContent's maul-unicode at the vendored tree for both libraries.
• The VERSION_EQUAL check lives only in the MAUL_UI_WINDOW glue, which the engine leaves off.
• A later Unicode is still built and checked with the others.

It matches the body and the build, and is written in the product's voice. With your tree comparison against both archives and the tag commits confirmed, nothing is open.