bst build --track doesnt allow granular selection of elements to track
It's unclear what the best approach for user facing API is, but it was agreed that:
most of the time a user wants to run a build while tracking new sources from their branches, the user does not want an unconditional recursive track of everything
For GNOME, this can relate for instance to building against a debootstrap debian base system; we would want a way to easily track only the modules that we want to run some CI on or build new versions of locally, without necessitating a GB of download to also receive a new base runtime to build on.
This is a similar issue to #113 (closed), as it will effect the user facing API for the same command and semantic, so it should probably be fixed together, also it blocks the 1.0 release because it constitutes an API change.
For this issue and #113 (closed) together, I would suggest an initial implementation that is entirely command line driven:
-
bst build --track <element1.bst> --track <element2.bst>
Allow one to specify specific elements to track during the build -
bst build --track <element1.bst> --save-tracking
New option for #113 (closed), allowing one to decide if new tracking information should be written out as a side effect
We could add --track-recurse
, which is mutually exclusive with the proposed new meaning of --track
, but I dont think it's entirely necessary.
In the future; we should consider having the project.conf
expose tracking domains for convenience, because the project is probably most well informed about which elements it makes sense to track, under which workflow scenario that works for that project - but this also can be introduced without any API break so lets discuss that later.