cabal haddock: imply dependencies, but gentler, i.e. don't override config/project settings

[ulysses4ever]

This is a WIP to fix #8725 as outlined in #8725 (comment).

High-level idea. Project configuration is built out of two pieces: config/project file settings and command-line flags: projectConfig <> cliConfig.

The way "cabal haddock implying --enable-documentation" (#8259 #8330) was implemented is it modified the latter (CLI flags). But that made the resulting code ignore anything from config/project files (flags are a Last monoid).

The idea here is instead of modifying CLI flags, add command-specific "default settings" (can differ between cabal's subcommands) that are prepended to the result, so: defaultConfigPerCommand <> projectConfig <> cliConfig.

I hope the high-level idea makes sense but I invite comments.

A low-level issue that I currently need input for is described in comments above, and in a nutshell, I want to know if flipping a default for documentation from Flag False to NoFlag looks okay. This asumes that NoFlag will turn into False eventually anyways.

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[ulysses4ever]

looks like global config gets documentation: False by default, represented by Flag False rather than NoFlag (which is what I hoped for). So, maybe, this idea won't work...

[ulysses4ever]

Trying to flip the default from Flag False to NoFlag and see how loud is the noise from failing CI...

[ulysses4ever]

@coot a haddock-project integration test:

cabal/cabal-install/tests/IntegrationTests2.hs

Lines 2796 to 2820 in d958545

	testHaddockProjectDependencies :: ProjectConfig -> Assertion
	testHaddockProjectDependencies config = do
	(_, _, sharedConfig) <- planProject testdir config
	-- `haddock-project` is only supported by `haddock-2.26.1` and above which is
	-- shipped with `ghc-9.4`
	when (compilerVersion (pkgConfigCompiler sharedConfig) > mkVersion [9, 4]) $ do
	let dir = basedir </> testdir
	cleanHaddockProject testdir
	withCurrentDirectory dir $ do
	CmdHaddockProject.haddockProjectAction
	defaultHaddockProjectFlags
	{ haddockProjectCommonFlags =
	defaultCommonSetupFlags
	{ setupVerbosity = Flag verbosity
	}
	}
	["all"]
	defaultGlobalFlags{globalStoreDir = Flag "store"}
	let haddock = "haddocks" </> "async" </> "async.haddock"
	hasHaddock <- doesFileExist haddock
	unless hasHaddock $ assertFailure ("File `" ++ haddock ++ "` does not exist.")
	cleanHaddockProject testdir
	where
	testdir = "haddock-project/dependencies"

fails with the patch here. This is probably due to switching from Flag False to NoFlag in defaultInstallFlags. Do you have any ideas how to fix it? I'm not very familiar with how haddock-project works, but it seems like it's making an assumption that may be defeated by this change. I'm wondering if making this assumption is a good idea or maybe the test should simply set more flags explicitly.

[coot]

It is a bit surprising that Flag False is fine, but NoFlag isn't; try to set the flag in haddock-project explicitly (haddock-project calls haddock).