chore(build): the feature matrix lives only in a 1,088-line hand-enumerated Makefile
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- rust
- Ambito
- build-system, ci-cd
Direzione di ricerca
Start by comparing the Makefile targets build, test, clippy, doc, and test-embedded with the CI calls in ci.yml at commit d9c7be0. Map the existing feature combinations and check whether any are missing from a target, then inspect the crate manifests to identify declared features. Choose one of the suggested approaches and add a check that every declared feature appears in at least one tested combination.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
Makefile is 1,088 lines, and most of it is hand-written cargo build|test|clippy|doc|check --package … --features "…" lines, one per crate and feature combination, repeated across the build, test, clippy, doc and test-embedded targets. CI calls these targets (make clippy, make test, make test-embedded, make check, make all), so the Makefile is the only place the supported feature matrix is written down.
Consequences:
- Adding or renaming a feature means editing the same combination in up to five targets, plus the crate manifest. Nothing checks that the five stay aligned, so a combination can be built but not linted, or linted but not documented.
- The matrix cannot be read by tools (e.g. to check that every declared feature is exercised at least once).
- It is the main reason the deprecated feature aliases are still in use in-tree.
Suggested work
Options, roughly in order of effort:
- Define each crate's feature combinations once as Make variables and have
build/test/clippy/dociterate over them. - Move the matrix into a small data file (TOML) consumed by an
xtaskor script, with the Makefile targets as thin wrappers. - Use
cargo hack --feature-powerset(with exclusions) for the host crates and keep explicit lists only for the embedded targets.
Whatever the choice, add a check that every feature declared in a crate manifest appears in at least one tested combination.
Notes
Based on reading the Makefile and ci.yml at d9c7be0. I did not check for combinations that are already missing from one of the targets; that would be a useful first step.
- Lingua principale
- Rust
- Stelle
- 101
- Fork
- 20
- Merge medio
- 2h 33m
- PR unite (30g)
- 90
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di aimdb-dev/aimdb
-
🏷️ good first issue enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
dependencies
Difficoltà 4/5 3-5 giorni Idoneità per principianti 44/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di aimdb-dev/aimdb
Issue simili
-
Panic on live viewport resize when unstyled elements exist in display: none subtreeForse già presa @GoCoder7 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
DioxusLabs/blitz#1488 ·
I maintainer di solito rispondono entro 1 giorno
-
S-Needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
vectordotdev/vrl#2042 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno