Skip to content

Conversation

@rgrinberg
Copy link
Member

This PR brings back #8356. It's clear that there's a need for this construct, but I felt that the PR had some shortcomings that had to be addressed, and I've attempted to do so here. The following changes were made to make this feature make more sense in the context of dune's other features:

  1. First, the field is renamed to enabled_if. This is inconsistent with opam, but is consistent with the rest of dune, which I deem as much more important. Second, the syntax is switched to pforms. Again, dune already has its own syntax for this stuff and we might as well reuse it.

  2. The field is given meaning independently of opam. It is interpreted exactly as --only-packages is. Packages which are "disabled" are essentially masked off the build, which I think is a fairly intepretation.

  3. I've added proper validation to this field to avoid users writing any garbage they want.

One important possibility for improvement is giving user proper error messages when packages are unavailable. I'm leaving that for future work as dune doesn't handle this properly in many other places already.

@rgrinberg rgrinberg force-pushed the enabled-if-packages branch 3 times, most recently from c19d90f to bc72ecb Compare December 9, 2025 23:29
Signed-off-by: Rudi Grinberg <me@rgrinberg.com>
Add [enabled_if] when defining packages. This construct is limited to
the variables we can inspect using [Sys_poll]. The interpretation of
this field is the same including or excluding it from the set of visible
packages with --only-packages.

Signed-off-by: Rudi Grinberg <me@rgrinberg.com>
@Alizter Alizter self-requested a review December 10, 2025 22:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants