Draft: de-bespoke build - #519
Conversation
Inert until CMakeLists.txt includes it. The rev-to-release resolution and its consistency checks are documented in the file header.
- The from-source alternative to the prebuilt, for revs and platforms with no published tarball and for instrumented sanitizer builds. - moqx itself is not built here; only the origin of the moxygen prefix differs between the two modes. - Inert until scripts/configure.sh --mode from-source drives it.
- Pins live in cmake/dependencies.cmake, and moxygen is consumed as an installed CMake package: either the published prebuilt or a superbuild prefix. - binaryDir is build/<presetName> so profiles coexist. - No .a preference in CMAKE_FIND_LIBRARY_SUFFIXES. folly-targets.cmake hardcodes libglog.so, so an .a-preferring Glog resolution loads both copies and glog's double flag registration crashes under ASan.
Two equal dependency modes, the pin table, and the scripts that drive them.
- With CPM the build dir's CMakeCache is the only state, so the ~500-line dispatcher and its marker files go. - --mode is deliberately explicit: a default would silently pick between an hours-long stack build and an uninstrumented prebuilt. - Job count is -j, then MOQX_BUILD_JOBS, then a RAM-derated default for sanitizer profiles; an explicit value is never clamped (distcc).
scripts/dev/lint.sh needs it and Ninja does not write it unasked.
- Only the trilogy, install-system-deps.sh, and moqx-run.sh are daily entry points; the rest move next to their audience. - Not a pure move: dev/sync-relay.sh is also repointed off the deleted submodule onto the pin.
- Dependency caches are content-keyed on the pins and restored by prefix: a bump would otherwise cold-download the full set in ~11 concurrent jobs. - Every build path installs system libraries through install-system-deps.sh. - version-release resolves the release from MOXYGEN_REV, not moxygen's newest tag, which would strand the release as a draft.
- Dead weight once CPM supplies both. - Split from the CPM wiring so the license-header churn stays a separate, mechanical diff.
MOQX_BUILD_TESTS defaults ON, so the release built every test executable and never ran ctest.
MOQBIN follows whatever moxygen the build resolved: ctest passes it per test, and scripts outside ctest source the moqx-tools.env the configure writes.
Both are build-level requirements rather than per-preset choices: a bare `cmake -S .` needs them too.
Both default to ~/.cache/moqx/cpm, so a raw `cmake --preset` build reuses the cached moxygen/catapult clones instead of re-fetching into its own _deps.
Every build and test passes an explicit build/<profile>.
- A missing package surfaced deep inside the folly stack, not as the install-system-deps.sh hint. - One Boost component list, so the superbuild's static-vs-shared probe and the check cannot name different sets.
- README drops the submodule bootstrap and `build.sh setup` for the trilogy. - ci-architecture documents the shared ~/.cache/moqx cache and how it is keyed. - release replaces the `.moxygen-release` tag file with the MOXYGEN_REV pin, so a release/* branch must freeze on a v*-tagged rev. - tools/.hidden only kept tools/ in git before it had content.
- CI runs scripts/dev/format.sh; lint.sh is a manual entry point. - The targets' tools/*.cc globs never matched anything.
- The static libs are not consumable without installed headers or an install(EXPORT). - They bloat the docker image and the release tarballs.
Tests gate on MOQX_BUILD_TESTS, and no subproject reads BUILD_TESTING.
- Nothing built or registered changes. - The load test stays unregistered: it needs a live relay. - The shell-test blocks stay explicit: their properties vary.
One SanitizerFlags.cmake shared with the superbuild, and a moqx_warnings INTERFACE target linked PRIVATE so nothing propagates to consumers.
- About two thirds of compile_commands.json is CPM-fetched dependency code. - Making .clang-tidy load surfaces ~18k warnings; that is #518.
Each restated its own code and ran past the 3-line cap.
0ec8de8 to
c7bb4f2
Compare
I see the benefits of some simplification, and improved organization. I neither love nor hate the submodule approach. I think a full walk-thru would help and being clear on some key workflows. one nagging problem that is handled to some extent in the current model (not perfect) is pr validation against the dependency profile, including our submodules, that exist in main. the other workflow difficulty is the case where you have changes in moqx that depend some unmerged work in moxygen . oh also note now openmoq/moxygen maintains artifacts for snapshot-latest and full tagged releases only... we may want to reexamine that approach too. |
| # on the next reconfigure of an existing build dir. A cached pin would silently | ||
| # shadow the file's value. | ||
| set(MOXYGEN_REPOSITORY "openmoq/moxygen") | ||
| set(MOXYGEN_REV "a1c42e1a0e0305484eb6cbcfd8c228a4685cade1") |
There was a problem hiding this comment.
I would point to this as one of the motivating fixes.
This is now just a plain text file. Rebase, merging, diffing now works as with any ordinary file.
Conceptually, submodules work as this simple pointer, but them being special makes them more difficult to work with. Because
- Commands don't recourse by default.
- The submodule state lives in multiple-places that can desync (.gitmodules, .git/config, and the actual working tree)
- Different tools shows different diffs.
Very much a draft that needs more passes.
Goal
Make the repo easier to understand and work with for newcomers.
and extension points are predictable.
submodule.recurse=true. Still a pain.submodules.
the source along. Optional submodule checkout is worse.
Breaking changes
This change is