Refactor ComponentEnabledSpec into ComponentRequestedSpec.
In the previous documentation for 'ComponentEnabledSpec', I claimed that enabled components were buildable, as well as requested by the user. In the course of working on #3847, however, I realized that I hadn't actually *checked* that the component was buildable anywhere. In particular, the 'ComponentDisabled' reason was *never used*. This mostly didn't cause problems, however, because when we 'flattenPD' all non-buildable components get deleted, so you basically never actually have a non-buildable 'Component'. But it still seemed a bit silly, so I fixed it by doing this: 1) I introduce a new concept of a component being requested, which captures the use of --enable-tests and friends. This does NOT imply buildability. Renamed ComponentEnabledSpec to ComponentRequestedSpec 2) A component is enabled if it is requested and buildable. If you give me a Component and a ComponentRequestedSpec I can tell you if it's enabled. However, if you give me a ComponentName I can't, because I have no idea if it's buildable. 3) Stopped reexporting ComponentRequestedSpec from Distribution.Simple.LocalBuildInfo 4) Added a test for attempting to specify a non-buildable component as a target. The test is accepting suboptimal output at the moment, see #3858. Signed-off-by: Edward Z. Yang <email@example.com>
Showing with 206 additions and 54 deletions
Cabal/Distribution/Types/ComponentEnabledSpec.hs → Cabal/Distribution/Types/ComponentRequestedSpec.hs