-
Notifications
You must be signed in to change notification settings - Fork 696
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dubious value auto-detected for hslogger's buildtests flag #3492
Comments
I'm not sure if we can really do anything better here. In many (other) cases, it is explicitly the desire to respect the default flag setting as much as possible. I'm somewhat surprised what the purpose of this particular flag is. Sounds as if one would get exactly the desired behaviour if the flag was just removed. |
That is what I thought, too, that flag seems like a complete re-implementation of --enable-tests and it should probably be removed. I realize that there is no obvious one true correct solution for what the solver should do in this particular case and leaving everything as-is is probably not a bad choice. Still, it feels a little odd that |
I looked at hslogger's history, and it seems like the |
I think that the solver should continue to prefer flags' default values. We could add a flag to cabal to change that preference or force components to be buildable, if that would be a useful feature. I'm closing this issue, though, since it seems like the best solution is to remove the |
I'm not sure what to make of the following behavior in Cabal 1.24.
hslogger
has a flagbuildtests
that marks the test suite "buildable" when enabled, but it defaults to "disabled". Now, the effective value of the flag is determined automatically by Cabal, but it sticks to the "disabled" setting, apparently not realizing that it could build the test suite if "enabled" would be chosen. As a result, users cannot run the test suite unless they realize that flag exists and specify it explicitly:Now I wonder: are we happy with that result? Or can a legitimate case be made that Cabal should strive to maximize the set of buildable components in a package?
The text was updated successfully, but these errors were encountered: