[dimpase]

Description

Make git submodule deinit --all followed by -DGIT_SUBMODULE=OFF work with the CMake build. Previously, disabling checkout updates still registered source builds for empty submodule directories. Missing engine sources and Emacs templates also prevented an external-dependency build.

There is no new CMake option. Source build rules are registered only when the corresponding checkout is populated. Absent memtailor, mathic and mathicgb sources default to the installed providers from #4728. Missing or unusable external libraries produce a configuration error when no source fallback exists. Absent Emacs sources are skipped while Prism, Vim and Pygments generation continues.

From the repository root, after installing the external dependencies:

git submodule deinit --all
cmake -S M2 -B build-external -G Ninja -DGIT_SUBMODULE=OFF \
  -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/path/to/dependencies

CMake does not run deinit itself. With populated checkouts, GIT_SUBMODULE=OFF still allows bundled builds without updating those checkouts. Use a fresh build directory when changing providers.

Non-submodule download recipes retain their existing behavior. Autotools behavior is unchanged; the shared grammar script receives one conditional controlled by the CMake invocation.

Temporary dependency pins

CI uses fixed memtailor, mathic and mathicgb commits because the latest releases checked on 2026-10-23 lack the required installed package metadata. #4761 records the revisions, required upstream changes, temporary build instructions and per-library release follow-up. Compatible installed packages with those changes backported also work. The workflow and M2/BUILD/README.md link the issue.

Related issues and pull requests

Depends on #4728 and the narrowed #4757; their commits are included for testing. #4757 now preserves completed dependency-build stamps.

Replaces the approach in #4725, which remains open as a draft. #4730 builds on this branch to remove bundled Emacs support entirely.

Testing

• Initialized the three engine-library submodules in a temporary checkout, ran git submodule deinit --all, confirmed the repositories remained cached, and restored the same revisions without downloading them again.
• Fresh macOS builds with deinitialized submodules passed through both CMake package discovery and pkg-config-only discovery at a custom prefix. Both built M2-core, M2-editors and M2-unit-tests; core --check 1 and all 275 engine unit tests passed in each build.
• Ninja target and compiler-dependency audits found no submodule build targets or consumed headers in either external build.
• Restored engine checkouts defaulted to bundled providers with GIT_SUBMODULE=OFF; memtailor, mathic and mathicgb built successfully.
• Missing FLINT, an explicit FLINT source-build request without its checkout, and an explicit absent bundled memtailor provider all failed with diagnostics.
• Workflow checks and diff checks passed. Actionlint uses the repository's existing ubuntu-26.04 runner label configuration and skips ShellCheck for pre-existing shell warnings.
• CI covers system-prefix CMake discovery and custom-prefix pkg-config discovery after deinitializing populated engine checkouts. Existing bundled jobs remain. Results for this revision are reported by the PR checks.

Full documentation/package installation was not repeated locally.

Release notes

CMake supports external-dependency builds with deinitialized submodules and the existing GIT_SUBMODULE=OFF option.

AI disclosure

• 5 — AI produced the content with minimal human review.

Tools and models used: OpenAI Codex.
How AI was used: implementation, revision, automated validation and documentation.
Verification: Codex ran the checks listed above; the author reviewed the design and subsequent documentation revisions.

License

• My changes use the existing license of the affected files or package.
• I release my new material under the GNU GPL, version 2 or later.

[mahrud]

What problem is this new option solving that GIT_SUBMODULE=off doesn't already solve? Will adding a very similarly named option with largely the same purpose make building M2 any easier?

On a general note, opening an AI generated pull request which explicitly says "human review remains pending" and marking it as ready for review and even requesting other humans to review it, without the "author" first going beyond "minimal human review" seems deeply disrespectful. I implore the reviewers to avoid normalizing this trend by volunteering their time to review when the "author" didn't bother doing so first.

[dimpase]

@mahrud : GIT_SUBMODULE=OFF just suppresses git submodule update, right? That is, you might have existing submodule checkouts, and they are still taken into consideration.

USE_SUBMODULES=OFF makes them truly ignored, even if they are present.
A destructive alternative, to just trash these checkouts, is probably easier, but, well, destructive.

I read the code in the author's capacity - a reviewer cannot be me. Sorry if the 🤖's notice sounded careless.
I'll fix it.

[mahrud]

git submodule deinit will clear the submodules for you, and it's not destructive, meaning M2/submodules/* are cleared but anything previously downloaded remains cached under .git/modules.

[mahrud]

I read the code in the author's capacity - a reviewer cannot be me.

So you really read what your agent wrote here and concluded this was okay?

[dimpase]

I read the code, yes

[dimpase]

hashes are temporarily, until new releases of these packages are made with the necessary fixes (the latter are merged, but still unrelated)

[dimpase]

git submodule deinit will clear the submodules for you, and it's not destructive, meaning M2/submodules/* are cleared but anything previously downloaded remains cached under .git/modules.

good catch! It's disappointing that 🤖 missed it.
This simplifies the whole thing a lot.

[mahrud]

Is this hardcoded list also temporary, or are you fine with this, or just not read this far?

[dimpase]

what's wrong there? this is the current submodules list, and cmake encourages explicit lists, no?

[mahrud]

good catch! It's disappointing that 🤖 missed it.

Your coding agent isn't responsible for PRs with your name, you are! It's really disappointing that you insist on pushing AI slop after repeatedly being shown its problems.

In the PR you closed you said:

perhaps the bottom line here is that software in submodules become a problem for the build system as soon as they start competing with their system-wide analogs;

This is plainly false! Submodules have source code, not built libraries, and it's very easy to choose whether a dependency is used from the system or built from source in a submodule. If you don't know how to do this then you should ask for help rather than having your coding agent open a pull request!