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

Implement --cabal-file, allows multiple Cabal files in directory #3553

Merged
merged 1 commit into from
Jul 24, 2016

Conversation

ezyang
Copy link
Contributor

@ezyang ezyang commented Jul 14, 2016

This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well. If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code. Some bigger
refactoring needed, see #3552.

Signed-off-by: Edward Z. Yang [email protected]

@phadej
Copy link
Collaborator

phadej commented Jul 14, 2016

So cabal check doesn't support --cabal-file with this?

@ezyang
Copy link
Contributor Author

ezyang commented Jul 14, 2016

Yes, and supporting it would require quite a bit of faffing about.

@23Skidoo
Copy link
Member

Bikeshedding: we might want to call it --package-description in case we later add support for other package description formats (e.g. hpack).

/cc @dcoutts

@ezyang
Copy link
Contributor Author

ezyang commented Jul 14, 2016

OK, sure (although it's hard to imagine the library getting support for hpack; it's more of a cabal-install thing.)

@phadej
Copy link
Collaborator

phadej commented Jul 15, 2016

I'd keep it as --cabal-file, and if we later would like to add --package-description we can, yet --cabal-file would be always parsed as cabal file (e.g. we could add --hpack-file too)

--package-description needs to guess, and sometimes you really want the tool you use not to guess at all, just do what it's told.

note to myself: verify what automatic reconfiguration can be disabled with some flag

@ezyang
Copy link
Contributor Author

ezyang commented Jul 16, 2016

Well, I have the patch to put it either way.

@ezyang ezyang mentioned this pull request Jul 21, 2016
38 tasks
@hvr
Copy link
Member

hvr commented Jul 23, 2016

Please take into account we'll also need a way to specify the cabal.project file location when designing a name for this

@ezyang
Copy link
Contributor Author

ezyang commented Jul 23, 2016

Well... --cabal-project for that one?

@hvr
Copy link
Member

hvr commented Jul 23, 2016

Alright, we'd have

  • --config-file to specify an alternative ~/.cabal/config
  • (suggested) --cabal-file to speficy an alternative *.cabal file

but then, for consistency, I'd suggest

  • --project-file to specify a non-default cabal.project file

This is primarily intended for use with the Cabal test suite (allowing
us to easily specify multiple Cabal packages for the same Haskell source
files), but maybe some end-users will find it useful as well.  If there
are multiple Cabal files in the current working directory, --cabal-file
(for configure) allows you to disambiguate which one to build with.

There's a big hack to handle the BOM check, as it is inconvenient to
plumb the flag value all the way to the check code.  Some bigger
refactoring needed, see haskell#3552.

Signed-off-by: Edward Z. Yang <[email protected]>
@23Skidoo
Copy link
Member

@ezyang BTW, don't we need a note in the manual about --cabal-file?

@ezyang
Copy link
Contributor Author

ezyang commented Aug 12, 2016

Well, I wasn't intending for it to be a user-visible feature. If we put it in the manual, we need to teach cabal-install how to handle it too, because cabal-install also reads in cabal files itself.

@23Skidoo
Copy link
Member

There should be a place for documenting non-user-visible features like --exact-configuration and this one, but I guess this will have to wait until someone rewrites the user guide.

@23Skidoo
Copy link
Member

Added a line to the changelog (858981e).

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

Successfully merging this pull request may close these issues.

4 participants