Improve build-type defaulting
#4958
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This refactoring unifies the defaulting logic into a single place paving the way for changing the defaulting logic.
This implements the following defaulting rules:
* For `cabal-version:2.0` and below, default to the `Custom`
build-type unconditionally (legacy defaulting)
* Otherwise, if a `custom-setup` stanza is defined, default to
the `Custom` build-type; else default to `Simple` build-type.
This gets us better defaults for the two most popular use-cases, and
which can be statically inferred by only looking at the `.cabal` file.
This allows us to bring down the minimal (modern) trivial cabal
package definition down to a single file with 4 lines:
cabal-version: 2.1
name: mu
version: 0
library
NB: We don't need any `Setup.hs` file, as `cabal sdist` will magically
generate one on the fly.
This tweaks the existing `CustomPlain` test to test the legacy defaulting logic for the unconditionally `Custom` default. Morever, a new `SimpleDefault` test has been added which tests that `cabal-version:2.1` does indeed infer `build-type: Simple` when there is no `custom-setup` stanza defined.
|
In a future refactoring, |
|
Yes, makes sense. |
|
Test failure is spurious, some |
23Skidoo
approved these changes
Dec 18, 2017
phadej
reviewed
Dec 18, 2017
| @@ -448,20 +448,20 @@ checkFields pkg = | |||
| "Package names with the prefix 'z-' are reserved by Cabal and " | |||
| ++ "cannot be used." | |||
|
|
|||
| , check (isNothing (buildType pkg)) $ | |||
| , check (isNothing (buildTypeRaw pkg) && specVersion pkg < mkVersion [2,1]) $ | |||
There was a problem hiding this comment.
This is great change, which one should mention in the changelog, It's updated in the manual (great!), but let's advertise this change in Changelog too.
Optionally, we can add a section in changelog gathering all cabal format related changes.
There was a problem hiding this comment.
Right!
Fwiw, I've got more related changes to for cabal check & build-type in the pipeline; the idea about structuring the changelog is a good one too, although I've been wanting to have an explicit cabal spec changelog in the user's guide as well... :-)
hvr
added a commit
to hvr/cabal
that referenced
this pull request
Jan 6, 2018
This is a follow-up to haskell#4958 which opened up the opportunity to do this make-illegal-states-unrepresentable refactoring as well.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A personal DRY-pet-peeve of mine when writing
.cabalfiles from scratch is forgetting about declaring thebuild-type, which historically will then be inferred to beCustomwhich is almost always not what is desired. Instead, a better default isSimpleas that represents the most basic and recommendedbuild-type. Morever, starting withcabal-version:1.24, we have a redundant signal in the.cabalfile to statically imply a custombuild-type, namely thecustom-setupstanza.To this end, this PR finally removes this papercut by improving the defaulting to use the following simple rules:
cabal-versionis set to2.1or higher, the default isSimpleunless acustom-setupstanza exists, in which case the inferred default isCustom.cabal-versions below2.1, the default isCustomunconditionally (legacy defaulting).This allows us to bring down the minimal (modern) trivial cabal package definition down to a single file with 4 lines:
NB: We don't need any
Setup.hsfile, ascabal new-builddoesn't need any, andcabal sdistwill magically generate one on the fly and include it in the source distribution.Please include the following checklist in your PR: