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

Replace flag-defaulting hack by proper solution #4886

Merged
merged 5 commits into from
Feb 12, 2018
Merged

Conversation

hvr
Copy link
Member

@hvr hvr commented Nov 12, 2017

This is not finished yet; this is supposed to address issues like #4737 or #5139

/cc @alexbiehl


Regressions:

  • (note: this is specific to the all target)
    $ cabal new-haddock all
    Resolving dependencies...
    fromFlag NoFlag. Use fromFlagOrDefault
    CallStack (from HasCallStack):
      error, called at ./Distribution/Simple/Setup.hs:172:21 in Cabal-2.1.0.0-inplace:Distribution.Simple.Setup
      fromFlag, called at ./Distribution/Client/CmdHaddock.hs:156:32 in cabal-install-2.1.0.0-inplace:Distribution.Client.CmdHaddock
    

@fgaz
Copy link
Member

fgaz commented Nov 12, 2017

Note to self: this may affect #4879

@hvr
Copy link
Member Author

hvr commented Nov 12, 2017

That CI passes is quite deceptive, as with the PR as it stands, cabal new-haddock all runs into a flag-related bottom rightaway... (cabal new-haddock libs however works fine)

@fgaz
Copy link
Member

fgaz commented Nov 12, 2017

Can we remove that LANGUAGE ViewPatterns now or is it needed elsewhere?

@hvr
Copy link
Member Author

hvr commented Nov 12, 2017

@fgaz which one? my patch removes already a couple of those...

@fgaz
Copy link
Member

fgaz commented Nov 12, 2017

@hvr I looked at CmdInstall and assumed you leaved it on the other modules too, but apparently I picked the exception, not the rule

@23Skidoo
Copy link
Member

23Skidoo commented Jan 3, 2018

@hvr What's the status of this?

@hvr
Copy link
Member Author

hvr commented Jan 7, 2018

@23Skidoo I've just rebased this, and will try to use it locally and try to observe regressions (which I'll report here in this ticket); but generally I think we want to merge this, and fix fromFlag-related exceptions as they get observed/reported.

@@ -1627,7 +1620,10 @@ installCommand = CommandUI {
++ " " ++ (map (const ' ') pname)
++ " "
++ " Change installation destination\n",
commandDefaultFlags = (mempty, mempty, mempty, mempty),
commandDefaultFlags = (commandDefaultFlags configureCommand,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is possibly wrong

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nevermind, the commits were in the wrong orde

@@ -1118,7 +1108,10 @@ upgradeCommand = configureCommand {
commandSynopsis = "(command disabled, use install instead)",
commandDescription = Nothing,
commandUsage = usageFlagsOrPackages "upgrade",
commandDefaultFlags = (mempty, mempty, mempty, mempty),
commandDefaultFlags = (commandDefaultFlags configureCommand,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is possibly wrong

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nevermind, the commits were in the wrong order

@hvr
Copy link
Member Author

hvr commented Feb 8, 2018

After brainstorming w/ @alexbiehl it appears like we want (c.f. #4737) something for the haddock flags in the style of

resolveSolverSettings :: ProjectConfig -> SolverSettings

resolveBuildTimeSettings :: Verbosity -> CabalDirLayout -> ProjectConfig -> BuildTimeSettings

specifically,

resolveHaddockSettings :: _ -> ProjectConfig -> HaddockSettings

(where _ is yet to be determined; could be empty) ...and a new type HaddockSettings to hold all/most haddock* fields from ProjectConfig.

EDIT: after some more thought; I'm not so sure about this anymore. It's more tricky

isRequested _ ExeKind = fromFlag (haddockExecutables haddockFlags)
isRequested _ TestKind = fromFlag (haddockTestSuites haddockFlags)
isRequested _ BenchKind = fromFlag (haddockBenchmarks haddockFlags)
isRequested _ FLibKind = fromFlagOrDefault False (haddockForeignLibs haddockFlags)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in my local version I had a comment along the lines of

    -- TODO/HACK, we encode some defaults here as new-haddock's logic;
    -- make sure this matches the defaults applied in
    -- "Distribution.Client.ProjectPlanning"; this may need more work
    -- to be done properly
    --
    -- See also https://github.com/haskell/cabal/pull/4886

which may need to be extended even further to point out that this gives CLI flags unduly importance over per-package cabal.project settings; which is the thing we'd need to do properly in future work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will add the comment

@hvr hvr changed the title WIP: Replace flag-defaulting hack by proper solution Replace flag-defaulting hack by proper solution Feb 12, 2018
@hvr hvr added this to the 2.2 milestone Feb 12, 2018
@hvr hvr merged commit abaf365 into haskell:master Feb 12, 2018
@hvr hvr deleted the pr/issue-4737 branch February 12, 2018 18:35
@hvr
Copy link
Member Author

hvr commented Feb 12, 2018

I've merged this as this enables other work to be unblocked (such as #4840)

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

Successfully merging this pull request may close these issues.

4 participants