Add program prefix and suffix to BuildOptions

[sheaf]

This commits adds two new fields of BuildOptions, namely programPrefix and programSuffix. This allows the installed executable program prefix and suffix to be set by SetupHooks for packages with build-type: Hooks.

---

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.
• 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]

Should cabal-install be updated to use these fields to handle affixes (prefixes and suffixes)? It handles them today on the higher level, but now, if we can do it on the library level, we add redundancy?

[sheaf]

Should cabal-install be updated to use these fields to handle affixes (prefixes and suffixes)? It handles them today on the higher level, but now, if we can do it on the library level, we add redundancy?

Which part of the cabal-install codebase are you referring to specifically?

All I could find was this, in Distribution.Client.CmdInstall:

ignoreProgramAffixes :: ConfigFlags -> ConfigFlags
ignoreProgramAffixes configFlags =
  configFlags
    { configProgPrefix = NoFlag
    , configProgSuffix = NoFlag
    }

[ulysses4ever]

I'm talking about these configProgPrefix/configProgSuffix. Are setup hooks not able to leverage those? Or vise versa?

[sheaf]

I'm talking about these configProgPrefix/configProgSuffix. Are setup hooks not able to leverage those? Or vise versa?

SetupHooks don't use ConfigFlags; ConfigFlags is part of the command-line interface for ./Setup.

[ulysses4ever]

@sheaf my bad. I dived a little deeper to try to substantiate my hunch, and here is the place that bothers me:

cabal/Cabal/src/Distribution/Types/LocalBuildInfo.hs

Lines 318 to 322 in e6ff0cc

	progPrefix, progSuffix :: LocalBuildInfo -> PathTemplate
	progPrefix (LocalBuildInfo{configFlags = cfg}) =
	fromFlag $ configProgPrefix cfg
	progSuffix (LocalBuildInfo{configFlags = cfg}) =
	fromFlag $ configProgSuffix cfg

Shouldn't these read from the new build options instead? Something like:

progPrefix, progSuffix :: LocalBuildInfo -> PathTemplate
progPrefix lbi@(LocalBuildInfo{configFlags = cfg}) =
  fromMaybe
    (fromFlag $ configProgPrefix cfg)
    (programPrefix lbi)
progSuffix lbi@(LocalBuildInfo{configFlags = cfg}) =
  fromMaybe
    (fromFlag $ configProgSuffix cfg)
    (programSuffix lbi)

[jappeace]

Hi, some questions because I'm curious.
Why would you want this?
(Isn't there an issue for this as well?)

Also, wouldn't a test be helpful to assert the prefix and suffix gets passed down in a hook build type situation?

[tdammers]

This does not actually introduce any code that uses these fields, does it?

[sheaf]

@sheaf my bad. I dived a little deeper to try to substantiate my hunch, and here is the place that bothers me:

cabal/Cabal/src/Distribution/Types/LocalBuildInfo.hs

Lines 318 to 322 in e6ff0cc

	progPrefix, progSuffix :: LocalBuildInfo -> PathTemplate
	progPrefix (LocalBuildInfo{configFlags = cfg}) =
	fromFlag $ configProgPrefix cfg
	progSuffix (LocalBuildInfo{configFlags = cfg}) =
	fromFlag $ configProgSuffix cfg

Shouldn't these read from the new build options instead? Something like:

progPrefix, progSuffix :: LocalBuildInfo -> PathTemplate
progPrefix lbi@(LocalBuildInfo{configFlags = cfg}) =
  fromMaybe
    (fromFlag $ configProgPrefix cfg)
    (programPrefix lbi)
progSuffix lbi@(LocalBuildInfo{configFlags = cfg}) =
  fromMaybe
    (fromFlag $ configProgSuffix cfg)
    (programSuffix lbi)

Yes, excellent point. The values in ConfigFlags are just for the CLI, once the data makes it into BuildOptions we should always pull from there. I'm fixing this now.

[sheaf]

Why would you want this?

This was requested in #11168.

Also, wouldn't a test be helpful to assert the prefix and suffix gets passed down in a hook build type situation?

This does not actually introduce any code that uses these fields, does it?

I added a test now.

[jappeace]

Thanks 🙏🏽