A good rule of thumb for automatic flag selection is to make
"constraints" induced on dependency solver disjoint, which would make
flag values a function of install plan.
E.g.
if flag(old-base)
build-depends: base <4
else
build-depends: base >=4
Given an install plan, I can tell what value the `old-base` would been
assigned. That is deterministic function.
I don't see how you would translate `conflicts` to package dependency
problem constraint.
Importantly: having `crypton` and `cryptonite` in different parts of
install plan is completely fine. No individual package (author) should
be able dictate that you cannot use some other package in the same project.
So, the fake-depends https://github.com/haskell/cabal/issues/11053 I
linked **adds dependency to be satisfied** (just not exposed), while
unrestrained `constraints` proposed in that issue later would be too
powerful.
- Oleg
On 3/6/26 04:12, Viktor Dukhovni via ghc-devs wrote:
On Thu, Mar 05, 2026 at 11:31:17AM +0100, Henning Thielemann via ghc-devs wrote:
AI hallucination apparently. I was on a plane with spotty Wifi, and
tried to make to with bad advice from Gemini. So it seems there isn't
any practical way to express that `tls` **requires** the `use_crypton`
flag in `mlkem` not only in its own build, but also when built as a
dependency of other packages. :-(
Ok, I see why the automatic flag does not solve the problem: In terms of
package dependencies there is no conflict for Cabal between `crypton` and
`cryptonite` and thus it chooses both of them. So, Cabal would actually need
something like a "conflicts" field in the package description.
Yes, the Gemini AI was hallucinating its existence, but perhaps that's
not entirely a bad idea for a new feature.
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
