0.14.0: rules-qt-xim-base declares xim:qt-base, qtbase and qttools with the QtQml library lupdate loads; the console Qt fixture uses it

Author: Sunrisepeak

.github/workflows/ci.yml

@@ -1662,7 +1662,7 @@ jobs:
       # A console program: QtCore, which is what Linux is served for. QtGui
       # loads libdbus, which the ecosystem does not publish, so the Widgets
       # fixture runs on Windows only.
-      - name: rules-qt runs moc, rcc and lrelease, with the SDK from xim:qt
+      - name: rules-qt runs moc, rcc, lupdate and lrelease, with the SDK from xim:qt-base
         run: bash .github/scripts/check-deps-and-qt.sh qt-consumer
 
   # ── THE SAME RULE ON THE OTHER TWO PLATFORMS ────────────────────────────────
@@ -2337,7 +2337,7 @@ jobs:
       - name: deps-cmake builds a CMake subproject as an action and links it
         run: bash .github/scripts/check-deps-and-qt.sh cmake-consumer
 
-      - name: rules-qt runs moc, rcc and lrelease, with the SDK from xim:qt
+      - name: rules-qt runs moc, rcc, lupdate and lrelease, with the SDK from xim:qt-base
         run: bash .github/scripts/check-deps-and-qt.sh qt-consumer
 
       # Windows and macOS: QtGui's dependencies are the system's there. On Linux

README.md

@@ -78,7 +78,7 @@ engine's own module family and is not used here.
 | `rules-cuda` | `mcpp.rules.cuda` | 2026.9.6.6 | `[build] accel = "cuda…"`, a constrained glob for `*.cu`; the clang route with an LLVM toolchain, the nvcc route with a GCC one |
 | `rules-hip` | `mcpp.rules.hip` | 2026.9.6.6 | `[build] accel = "hip, cuda12.9+{sm_89}"`, a constrained glob for `*.hip`. On the NVIDIA platform HIP is a header layer over the CUDA runtime, so the compiler is the project's own clang and there is no ROCm on the machine |
 | `rules-metal` | `mcpp.rules.metal` | 2026.9.8.1 | the Metal toolchain of the macOS host's Xcode, located rather than installed: Xcode is not redistributable, so no payload is declared. `.metal` sources the project names on a macOS or iOS row become one `xcrun --sdk <sdk> metal` action per shader (`-MMD`, so an edited `#include` recompiles the shaders that include it) and one `xcrun --sdk <sdk> metallib` action per library, placed beside the program with `mcpp::deploy` under `metallib/`, which `dist-apple` maps into the bundle's resources. `compile(shaders)` compiles one source several times with definitions of its own, one library per `shader`; `options::library` links every shader into one library (`default` is the one `newDefaultLibrary` finds). Before planning anything the rule asks `xcrun --sdk <sdk> --show-sdk-path` and `--find metal` / `--find metallib`, and refuses naming the command that answered nothing, because a missing SDK and a missing compiler have different remedies (Xcode 26 installs the Metal toolchain as a separate component). A shader on any other row is refused naming the row. CI compiles the fixture on `macos-15` and checks each library's magic, and that a header edit recompiles only the shaders that include it |
-| `rules-qt` | `mcpp.rules.qt` | 2026.9.26.2 (mcpp#702) | a Qt 6 SDK: `rules-qt-xim` declares `xim:qt` 6.11.1 on the target axis, `rules-qt-xim-addons` adds `xim:qt-addons` (the additional libraries) as a second prefix, and `options::root` names an SDK from elsewhere. From 0.13.0. `moc` for every header under the package root that declares `Q_OBJECT`, `Q_GADGET` or `Q_NAMESPACE` and for a source that includes its own `<stem>.moc`; `uic` for `.ui`, `rcc` for `.qrc`, `lrelease` for `.ts` (named in `[build] sources` or in the options), each a `role = "source"` action with declared inputs. The modules are linked by full path, and the SDK's `bin/` (Windows) or `lib/` is a runtime search directory: the program's run path, `mcpp run`'s load path, `mcpp pack`'s closure, and on Windows the Qt DLLs the program imports placed beside it by the engine. The plugin directories `deploy_plugins` names are deployed beside the program. See [`deps-vcpkg`, `deps-cmake`, `deps-archive` and `rules-qt`](#deps-vcpkg-deps-cmake-deps-archive-and-rules-qt) |
+| `rules-qt` | `mcpp.rules.qt` | 2026.9.26.2 (mcpp#702) | a Qt 6 SDK: `rules-qt-xim` declares `xim:qt` 6.11.1 on the target axis, `rules-qt-xim-base` declares `xim:qt-base` instead (qtbase and qttools with the QtQml library lupdate loads, about a third of the download; 0.14.0), `rules-qt-xim-addons` adds `xim:qt-addons` (the additional libraries) as a second prefix, and `options::root` names an SDK from elsewhere. From 0.13.0. `moc` for every header under the package root that declares `Q_OBJECT`, `Q_GADGET` or `Q_NAMESPACE` and for a source that includes its own `<stem>.moc`; `uic` for `.ui`, `rcc` for `.qrc`, `lrelease` for `.ts` (named in `[build] sources` or in the options), each a `role = "source"` action with declared inputs. The modules are linked by full path, and the SDK's `bin/` (Windows) or `lib/` is a runtime search directory: the program's run path, `mcpp run`'s load path, `mcpp pack`'s closure, and on Windows the Qt DLLs the program imports placed beside it by the engine. The plugin directories `deploy_plugins` names are deployed beside the program. See [`deps-vcpkg`, `deps-cmake`, `deps-archive` and `rules-qt`](#deps-vcpkg-deps-cmake-deps-archive-and-rules-qt) |
 | `rules-slang` | `mcpp.rules.slang` | 2026.9.7.1 | `[build] accel = "vulkan1.2"`, a constrained glob for `*.slang`. Slang is a different language from GLSL rather than a second driver for it -- its own module system, generics, and targets beyond SPIR-V -- so it is a rule of its own. `.slang` is **not** in the engine's device-source table: this feature declares `device_extensions = [".slang"]` and `rule_module = "mcpp.rules.slang"`, and the engine routes it from there. That is the criterion for the whole arrangement -- a new device language costs no engine release. Since 0.7.0 it has the same `options::storage` axis as `rules-spirv` (header / object / sidecar), `options::extra_args` for the arguments the rule has no field for, and `options::per_file` for what one shader gets that the others do not -- a project with a `-fvk-use-gl-layout` and one shader needing `-emit-spirv-via-glsl` writes both without leaving one `compile()` call |
 | `rules-spirv` | `mcpp.rules.spirv` | 2026.9.6.6 | `[build] accel = "vulkan1.2"`, a constrained glob for the shader stages; compiles each shader through a `role = "source"` action and states which of the two compilers produced it |
 | `rules-swift` | `mcpp.rules.swift` | 2026.9.8.1 | the Swift compiler of the macOS host's Xcode or Command Line Tools, located rather than installed, as `rules-metal` locates its toolchain. From 0.12.0. The `.swift` sources a project names on a macOS or iOS row compile as one module named after the package: one whole-module `xcrun --sdk <sdk> swiftc -wmo -emit-object -target <triple>` action whose role is `object`, so the object joins every image of the package, and one `swiftc -typecheck -emit-objc-header-path` action whose role is `source`, whose directory `mcpp::include_dir` adds, so the package's C and C++ sources include `<module>-Swift.h`. `options::bridging_header` names a C header Swift sees without an import. The link receives the toolchain's `usr/lib/swift/<platform>` and the SDK's `usr/lib/swift` as search directories and `/usr/lib/swift` as a run path through `mcpp::link_flag`. Before planning anything the rule asks `xcrun --sdk <sdk> --show-sdk-path` and `--find swiftc`, and refuses naming the command that answered nothing; a Swift source on any other row is refused naming the row. Not supported: a Swift `import` of another package's module, and another package's C++ including this package's generated header, which both need an engine channel that publishes a package's interface directory to its dependents; and SwiftPM dependencies. CI builds `tests/swift-consumer` on `macos-15` -- a C++ program calling a `@_cdecl` Swift function that calls back into C -- and runs it |
@@ -1006,6 +1006,7 @@ int main() {
 |---|---|
 | `rules-qt` | `options::root`; nothing is downloaded |
 | `rules-qt-xim` | `xim:qt` 6.11.1: the official base package without documentation (qtbase, qtsvg, qtdeclarative, qttools, qttranslations) |
+| `rules-qt-xim-base` | `xim:qt-base` 6.11.1 in place of `xim:qt`: qtbase and qttools with the QtQml library `lupdate` loads, about a third of the download (56–73 MB); every module a widgets or console program links, without Qt Quick, qtsvg or Qt's own translations |
 | `rules-qt-xim-addons` | adds `xim:qt-addons` 6.11.1, every additional library, as a second prefix |
 
 | option | meaning |
@@ -1031,7 +1032,7 @@ A missing SDK, module or tool is a warning: the rule states what it can, and
 the build is where the absence fails.
 
 On Linux, Qt's official QtCore links glib, zstd and zlib and the shared
-`libstdc++`. `rules-qt-xim` declares the first three on Linux, and the rule
+`libstdc++`. `rules-qt-xim` and `rules-qt-xim-base` declare the first three on Linux, and the rule
 declares their `lib/` directories as runtime search directories; the program
 states `[build] cxx_runtime = "toolchain-coupled"` (mcpp's docs/20), so the
 process has one C++ runtime. The statement is project-wide because mcpp reads a

mcpp.toml

@@ -157,6 +157,12 @@ implies = ["rules-qt"]
 [features.rules-qt-xim-addons]
 implies = ["rules-qt-xim"]
 
+# `xim:qt-base`: qtbase and qttools with the QtQml library qttools' Linguist
+# tools load, without Qt Quick -- about a third of `xim:qt`'s download. For a
+# widgets or console program. 0.14.0.
+[features.rules-qt-xim-base]
+implies = ["rules-qt"]
+
 # NOT device rules: these embed or declare things a project already has, so they
 # claim no extension and name no rule module. A consumer calls them from its own
 # `build.mcpp`.
@@ -495,6 +501,14 @@ implies           = ["surface"]
 [target.'cfg(any(windows, linux, macos))'.feature-xlings.rules-qt-xim-addons]
 "xim:qt-addons" = "6.11.1"
 
+[target.'cfg(any(windows, linux, macos))'.feature-xlings.rules-qt-xim-base]
+"xim:qt-base" = "6.11.1"
+
+[target.'cfg(linux)'.feature-xlings.rules-qt-xim-base]
+"xim:glib" = ""
+"xim:zstd" = ""
+"xim:zlib" = ""
+
 # ── The environment `dist-appimage` needs ──────────────────────────────────
 #
 # ONE PAYLOAD, AND IT CARRIES TWO FILES. `appimagetool` builds the image, and

rules/qt.cppm

@@ -252,7 +252,11 @@ inline std::vector<std::filesystem::path> roots(const options& opt = {}) {
     };
     if (!opt.root.empty()) add(opt.root);
     else {
-        add(mcpp::xpkg_dir("xim", "qt"));
+        // `xim:qt` is the full base; `xim:qt-base` is its qtbase + qttools
+        // subset (`rules-qt-xim-base`). A project that declares both uses the
+        // full one.
+        const std::string full = mcpp::xpkg_dir("xim", "qt");
+        add(full.empty() ? std::string(mcpp::xpkg_dir("xim", "qt-base")) : full);
         add(mcpp::xpkg_dir("xim", "qt-addons"));
     }
     for (auto const& r : opt.extra_roots) add(r);
@@ -270,7 +274,7 @@ inline std::string root(const options& opt = {}) {
 
 // The SDK's shared-library directories, and on Linux those of the libraries
 // Qt's official QtCore expects the distribution to provide (glib, zstd, zlib,
-// declared from xim by `rules-qt-xim`), as runtime search directories
+// declared from xim by `rules-qt-xim` and `rules-qt-xim-base`), as runtime search directories
 // (SPEC-007 R4.1). The engine renders them as the program's run path, puts
 // them on `mcpp run`'s load path -- which reaches a library's dependencies
 // where the program's run path does not, because QtCore carries a RUNPATH of
@@ -308,8 +312,9 @@ inline bool compile(options opt = {}) {
     if (sdks.empty()) {
         detail::warn(std::format(
             "{}: no Qt SDK: options::root is {} and xpkg_dir(\"xim\", \"qt\") answered \"{}\". "
-            "Nothing Qt-specific is planned. The `rules-qt-xim` feature declares `xim:qt`, "
-            "which `mcpp build` provisions; a Qt from elsewhere is named with options::root.",
+            "Nothing Qt-specific is planned. The `rules-qt-xim` feature declares `xim:qt` and "
+            "`rules-qt-xim-base` declares `xim:qt-base`, which `mcpp build` provisions; a Qt "
+            "from elsewhere is named with options::root.",
             who, opt.root.empty() ? "empty" : "'" + opt.root + "' (no such directory)",
             std::string(mcpp::xpkg_dir("xim", "qt"))));
         return true;

tests/qt-consumer/mcpp.toml

@@ -1,5 +1,7 @@
 # Fixture: a Qt 6 program that exercises each of Qt's code generators and its
-# Linguist tool through `rules-qt`, with the SDK from `xim:qt`.
+# Linguist tools through `rules-qt`, with the SDK from `xim:qt-base` (qtbase,
+# qttools and the QtQml library lupdate loads); tests/qt-widgets-consumer
+# uses `xim:qt`.
 #
 # A console program on purpose: QtCore needs no display and no platform plugin,
 # so the same program is built and RUN on every host in the matrix. What it
@@ -31,7 +33,7 @@ modules    = true
 import_std = false
 
 [build-dependencies.mcpp]
-plugins = { path = "../..", features = ["rules-qt-xim"], host-module = true }
+plugins = { path = "../..", features = ["rules-qt-xim-base"], host-module = true }
 
 [build]
 # Qt's Linux libraries load the shared libstdc++ (`libstdc++.so.6`), so the