Closed soareschen closed 4 years ago
Ping. Is there any problem with this PR?
@soareschen @arybczak
Sorry for the slow response.
No, this all looks good (*), and I have recently been thinking about the same change.
\
(*) there is one problem: The cabal-version: 2.2
change breaks my CI which still uses older cabal versions. I don't mind at all dropping support for older cabal versions. The only problem is that I have been really annoyed with some haskell CI setup problems (not specific to brittany and certainly not to this PR) in the past few weeks.
I will push some attempt to upgrade the CI versions to fix this in a few minutes. Might take a few iterations to get it working though, so I probably won't get this ready today.
Hmm if I read the logs correctly, the CI stack version does not like the cabal-package version either. Have no idea how to upgrade that, apart from manually installing a new stack version in the image, which would be annoying.
I have instead downgraded package cabal-version to 2.0 which so far looks promising, see https://travis-ci.org/github/lspitzner/brittany/builds/683590901 nevermind it breaks, and I notice that cabal check
also has multiple issues with this anyway.
I will think on this, but I might go with the pragmatic choice of reverting the cabal-version/license-field change, and merging the rest.
@lspitzner I have reverted changes to the cabal version. Hope that helps.
great, thanks!
Motivation: We would like to include Brittany as a dependency to our Haskell project, and then call Brittany through
cabal run
instead of having a global installation ofbrittany
. The problem is that Cabal does not expose thebrittany
executable during runtime.By exposing the main function of
brittany
as a module, we can create an executable likemy-brittany
in our Cabal project, and then callcabal run my-brittany
instead ofbrittany
.This change is