Skip to content

Add program prefix and suffix to BuildOptions#11787

Merged
mergify[bot] merged 1 commit into
haskell:masterfrom
sheaf:hooks-prefix
Jun 28, 2026
Merged

Add program prefix and suffix to BuildOptions#11787
mergify[bot] merged 1 commit into
haskell:masterfrom
sheaf:hooks-prefix

Conversation

@sheaf

@sheaf sheaf commented May 5, 2026

Copy link
Copy Markdown
Collaborator

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!)

@sheaf sheaf force-pushed the hooks-prefix branch 2 times, most recently from 24c1c44 to bf07ec8 Compare May 5, 2026 11:39
@sheaf sheaf marked this pull request as ready for review May 5, 2026 11:40
@ulysses4ever

Copy link
Copy Markdown
Collaborator

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

sheaf commented May 6, 2026

Copy link
Copy Markdown
Collaborator Author

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

Copy link
Copy Markdown
Collaborator

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

@sheaf

sheaf commented May 6, 2026

Copy link
Copy Markdown
Collaborator Author

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

Copy link
Copy Markdown
Collaborator

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

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

jappeace commented May 13, 2026

Copy link
Copy Markdown
Collaborator

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 tdammers left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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

@sheaf

sheaf commented May 28, 2026

Copy link
Copy Markdown
Collaborator Author

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

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 sheaf force-pushed the hooks-prefix branch 2 times, most recently from c4daf04 to 3181f38 Compare May 28, 2026 08:36
@sheaf

sheaf commented May 28, 2026

Copy link
Copy Markdown
Collaborator Author

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.

@sheaf sheaf force-pushed the hooks-prefix branch 3 times, most recently from eafe997 to 5629b87 Compare May 28, 2026 11:47
@Mikolaj Mikolaj requested a review from jappeace June 4, 2026 17:49
@jappeace

jappeace commented Jun 4, 2026

Copy link
Copy Markdown
Collaborator

Thanks 🙏🏽

@Mikolaj

Mikolaj commented Jun 18, 2026

Copy link
Copy Markdown
Member

@sheaf: do you think it's ready to merge? If so, could you add a label? Do you think this should be backported to 3.18?

@sheaf

sheaf commented Jun 18, 2026

Copy link
Copy Markdown
Collaborator Author

@sheaf: do you think it's ready to merge? If so, could you add a label? Do you think this should be backported to 3.18?

Just need to update the structured test for CI. Yes, I think it would make sense to backport so that all the improvements to Hooks land in a single version.

@sheaf sheaf added merge me Tell Mergify Bot to merge and removed attention: needs-review labels Jun 18, 2026
@mergify

mergify Bot commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Queued — the merge queue status continues in this comment ↓.

@mergify mergify Bot added ready and waiting Mergify is waiting out the cooldown period merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days waiting too long automatically set by Mergify to trigger a warning labels Jun 19, 2026
@zlonast

zlonast commented Jun 27, 2026

Copy link
Copy Markdown
Collaborator

@sheaf may have missed it

@mergify

mergify Bot commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

Merge Queue Status

This pull request spent 7 hours 30 minutes 54 seconds in the queue, including 1 hour 53 minutes 16 seconds running CI.

Waiting for
  • any of: [🛡 GitHub branch protection]
    • check-neutral = Doctest Cabal
    • check-skipped = Doctest Cabal
    • check-success = Doctest Cabal
  • any of: [🛡 GitHub branch protection]
    • check-neutral = Meta checks
    • check-skipped = Meta checks
    • check-success = Meta checks
  • any of: [🛡 GitHub branch protection]
    • check-neutral = Validate post job
    • check-skipped = Validate post job
    • check-success = Validate post job
  • any of: [🛡 GitHub branch protection]
    • check-neutral = Bootstrap post job
    • check-skipped = Bootstrap post job
    • check-success = Bootstrap post job
  • any of: [🛡 GitHub branch protection]
    • check-neutral = Changelogs
    • check-skipped = Changelogs
    • check-success = Changelogs
All conditions
  • any of [🛡 GitHub branch protection]:
    • check-neutral = Doctest Cabal
    • check-skipped = Doctest Cabal
    • check-success = Doctest Cabal
  • any of [🛡 GitHub branch protection]:
    • check-neutral = Meta checks
    • check-skipped = Meta checks
    • check-success = Meta checks
  • any of [🛡 GitHub branch protection]:
    • check-neutral = Validate post job
    • check-skipped = Validate post job
    • check-success = Validate post job
  • any of [🛡 GitHub branch protection]:
    • check-neutral = Bootstrap post job
    • check-skipped = Bootstrap post job
    • check-success = Bootstrap post job
  • any of [🛡 GitHub branch protection]:
    • check-neutral = Changelogs
    • check-skipped = Changelogs
    • check-success = Changelogs
  • #approved-reviews-by >= 2 [🛡 GitHub branch protection]
  • #review-threads-unresolved = 0 [🛡 GitHub branch protection]
  • any of [🛡 GitHub branch protection]:
    • check-success = docs/readthedocs.org:cabal
    • check-neutral = docs/readthedocs.org:cabal
    • check-skipped = docs/readthedocs.org:cabal
  • any of [🛡 GitHub branch protection]:
    • check-success = fourmolu
    • check-neutral = fourmolu
    • check-skipped = fourmolu
  • any of [🛡 GitHub branch protection]:
    • check-success = hlint
    • check-neutral = hlint
    • check-skipped = hlint
  • any of [🛡 GitHub branch protection]:
    • check-success = whitespace
    • check-neutral = whitespace
    • check-skipped = whitespace
  • any of [🛡 GitHub branch protection]:
    • check-success = Check sdist post job
    • check-neutral = Check sdist post job
    • check-skipped = Check sdist post job

Reason

The merge conditions cannot be satisfied due to failing checks

  • docs/readthedocs.org:cabal
  • fourmolu
  • hlint
  • whitespace
  • Check sdist post job
  • Changelogs

Failing checks:

Hint

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

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`.

Fixes haskell#11168
@zlonast

zlonast commented Jun 28, 2026

Copy link
Copy Markdown
Collaborator

@Mergifyio queue

@mergify

mergify Bot commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

Merge Queue Status

This pull request spent 5 hours 31 minutes 58 seconds in the queue, including 5 hours 20 minutes 53 seconds running CI.

Required conditions to merge
  • #approved-reviews-by >= 2 [🛡 GitHub branch protection]
  • #review-threads-unresolved = 0 [🛡 GitHub branch protection]
  • any of [🛡 GitHub branch protection]:
    • check-success = Doctest Cabal
    • check-neutral = Doctest Cabal
    • check-skipped = Doctest Cabal
  • any of [🛡 GitHub branch protection]:
    • check-success = Meta checks
    • check-neutral = Meta checks
    • check-skipped = Meta checks
  • any of [🛡 GitHub branch protection]:
    • check-success = docs/readthedocs.org:cabal
    • check-neutral = docs/readthedocs.org:cabal
    • check-skipped = docs/readthedocs.org:cabal
  • any of [🛡 GitHub branch protection]:
    • check-success = Validate post job
    • check-neutral = Validate post job
    • check-skipped = Validate post job
  • any of [🛡 GitHub branch protection]:
    • check-success = fourmolu
    • check-neutral = fourmolu
    • check-skipped = fourmolu
  • any of [🛡 GitHub branch protection]:
    • check-success = hlint
    • check-neutral = hlint
    • check-skipped = hlint
  • any of [🛡 GitHub branch protection]:
    • check-success = Bootstrap post job
    • check-neutral = Bootstrap post job
    • check-skipped = Bootstrap post job
  • any of [🛡 GitHub branch protection]:
    • check-success = whitespace
    • check-neutral = whitespace
    • check-skipped = whitespace
  • any of [🛡 GitHub branch protection]:
    • check-success = Check sdist post job
    • check-neutral = Check sdist post job
    • check-skipped = Check sdist post job
  • any of [🛡 GitHub branch protection]:
    • check-success = Changelogs
    • check-neutral = Changelogs
    • check-skipped = Changelogs

@mergify mergify Bot added queued and removed dequeued labels Jun 28, 2026
mergify Bot added a commit that referenced this pull request Jun 28, 2026
mergify Bot added a commit that referenced this pull request Jun 28, 2026
@mergify mergify Bot merged commit e4d6c7c into haskell:master Jun 28, 2026
72 checks passed
@mergify mergify Bot removed the queued label Jun 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days merge me Tell Mergify Bot to merge ready and waiting Mergify is waiting out the cooldown period waiting too long automatically set by Mergify to trigger a warning

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants