Indeed this feature has been on my to-do list forever. This problem is complicated by the fact that we want to be able to instrument preprocessed code. Consider running bisect on code sources that use cppo for example.
Another design decision that needs review is the interaction with profiles. Originally, my idea was to have a special bisect profile that would setup instrumentation. However, people have been raising concerns that this is too inflexible. So we are likely to have this as a context option instead. Since this is becoming an issue for more people, I can certainly bump its priority. The first version of this is unlikely to address the limitation I've mentioned initially, would it still be useful for mirage? On Tue, Apr 9, 2019 at 11:11 PM Anil Madhavapeddy <[email protected]> wrote: > On 9 Apr 2019, at 00:02, Mindy Preston <[email protected]> wrote: > > > > Hi all, > > > > I recently got inspired to revisit test coverage information generation. > It seems that the current state of this ecosystem uses `dune` for building > and some instructions in `preprocess` stanzas to invoke `bisect_ppx`, which > itself has logic to only produce coverage information if an environment > variable is set when called in a certain mode. > > > > Unfortunately, while the *invocation* of `bisect_ppx` can be set > conditionally (see bisect_ppx's instructions[1]) for details), the > dependency on `bisect_ppx` is unconditional - even if the environment > variable isn't set, `dune build` will fail if `bisect_ppx` is not installed. > > > > It seems that most projects using `bisect_ppx` use a solution that > involves some pre-release massaging of `dune` files to remove `bisect_ppx` > from `preprocess (pps` stanzas, and then release an `opam` file that > doesn't mention `bisect_ppx`, but keep `bisect_ppx` in their > repository-local `opam` files. > > > > I think this kind of workflow is OK for repositories that have one or > two very involved maintainers, but it seems error-prone for MirageOS > repositories, where there's a team of maintainers that have varying amounts > of involvement. I can very easily imagine myself going to make a release > of a repository with this strategy and accidentally releasing the bisected > version. > > > > I'm interested if anyone has a solution in mind for this that's a bit > more automatic. > > > > This is indeed pending a fix in Dune; see > https://github.com/ocaml/dune/issues/57 > > I’ve copied Rudi in case he can comment on any blockers from the dune end > and whether this is a candidate to target for dune 1.10 (the 1.9 release is > just about ready to go out of the door in the next few days). > > regards, > Anil > >
_______________________________________________ MirageOS-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/mirageos-devel
