Skip to content
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

Closed
peti opened this issue Jun 11, 2016 · 5 comments
Closed

Dubious value auto-detected for hslogger's buildtests flag #3492

peti opened this issue Jun 11, 2016 · 5 comments

Comments

@peti
Copy link
Collaborator

peti commented Jun 11, 2016

I'm not sure what to make of the following behavior in Cabal 1.24. hslogger has a flag buildtests 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:

$ cabal get hslogger
Downloading hslogger-1.2.10...
Unpacking to hslogger-1.2.10/
$ cd hslogger-1.2.10/
$ cabal configure -v --enable-tests 
[...]
Configuring hslogger-1.2.10...
Flags chosen: buildtests=False, small_base=True
[...]
$ cabal test 
Package has no buildable test suites.

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?

@23Skidoo
Copy link
Member

/cc @grayjay, @kosmikus

@kosmikus
Copy link
Contributor

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.

@peti
Copy link
Collaborator Author

peti commented Jun 11, 2016

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 --enable-tests is given, there are test suites which could be built if the appropriate automatic flag were enabled, but Cabal just won't do it. Not sure what to do about it either.

@grayjay
Copy link
Collaborator

grayjay commented Jun 11, 2016

I looked at hslogger's history, and it seems like the buildtests flag was added before cabal supported test suites, when the component was an executable.

@grayjay
Copy link
Collaborator

grayjay commented Jun 20, 2016

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 buildtests flag from hslogger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants