Motivation
Sapling contains several components with different build and test workflows
For example, building the CLI currently involves running make oss from eden/scm, while other components use CMake, Cargo, Yarn, or getdeps.py.
Would the project be open to adding a root-level justfile that provides a consistent entry point for common contributor tasks?
Proposed approach
The justfile would wrap the existing build systems rather than replace CMake.
Possible recipes could include:
just build-clijust test-clijust build-edenfsjust testjust lintjust build-isl
The existing commands would remain usable directly, and CMake would continue to manage native builds.
Benefits
- Easier command discovery through
just --list
- A consistent interface from the repository root
- Less need for contributors to remember component-specific working directories
- No immediate migration or disruption to existing CI workflows
Questions
- Would maintainers find a root-level task runner useful?
- Which workflows should an initial
justfile expose?
- Would adding
just as a development dependency be acceptable?
Motivation
Sapling contains several components with different build and test workflows
For example, building the CLI currently involves running
make ossfromeden/scm, while other components use CMake, Cargo, Yarn, orgetdeps.py.Would the project be open to adding a root-level
justfilethat provides a consistent entry point for common contributor tasks?Proposed approach
The
justfilewould wrap the existing build systems rather than replace CMake.Possible recipes could include:
just build-clijust test-clijust build-edenfsjust testjust lintjust build-islThe existing commands would remain usable directly, and CMake would continue to manage native builds.
Benefits
just --listQuestions
justfileexpose?justas a development dependency be acceptable?