Skip to content

Re #11498 Better document Cabal's --semaphore=SEMAPHORE option#12022

Open
mpilgrem wants to merge 2 commits into
masterfrom
re11498
Open

Re #11498 Better document Cabal's --semaphore=SEMAPHORE option#12022
mpilgrem wants to merge 2 commits into
masterfrom
re11498

Conversation

@mpilgrem

@mpilgrem mpilgrem commented Jun 25, 2026

Copy link
Copy Markdown
Collaborator

EDIT: To be clear, this is only about documenting Cabal (the library) under runhaskell Setup.hs build and not about the executable provided by the cabal-install package.

This is follows GHC's dependency on semaphore-compat-2.0.0 (first reflected in GHC 9.12.5-rc2).

The terminology of the dependency package now:

  • introduces the concept of protocol versions for semaphores (there remains only one protocol version on Windows);
  • distinguishes server semaphores and corresponding client semaphores; and
  • distinguishes unversioned client semaphore names and client semaphore identifiers.

This conforms the language in Cabal's User Guide to that of the package.

This PR does not modify behaviour or interface

  • Patches conform to the coding conventions.
  • Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions). N/A

Comment thread doc/setup-commands.rst Outdated
Comment thread doc/setup-commands.rst Outdated
Comment thread Cabal/src/Distribution/Simple/Setup/Build.hs Outdated
@mpilgrem

Copy link
Copy Markdown
Collaborator Author

I've revised the suggested documentation to refer Cabal's users to GHC's boot package semaphore-compat and follow closely the language that package (> 1.0.0) uses to describe the relevant string.

@sheaf

sheaf commented Jun 30, 2026

Copy link
Copy Markdown
Collaborator

Thanks, this is looking much better. I made some more suggestions; please apply as you see fit, although I would like to avoid the "system semaphore" terminology as semaphore-compat-2.0 now implements its own notion of semaphore which technically aren't system sepahores on POSIX platforms.

I will open an MR against semaphore-compat to flesh out the documentation, I hope that you will be able to take a look at it.

Comment thread changelog.d/pr-12022.md Outdated
Comment thread changelog.d/pr-12022.md Outdated
Comment thread doc/setup-commands.rst Outdated
Comment thread Cabal/src/Distribution/Simple/Setup/Build.hs Outdated
@sheaf

sheaf commented Jun 30, 2026

Copy link
Copy Markdown
Collaborator

I will open an MR against semaphore-compat to flesh out the documentation, I hope that you will be able to take a look at it.

Wow, I realise there were a lot of bugs with the Haddocks in v2 of semaphore-compat. In particular, some named chunks of documentation were not rendering properly. I apologise for that; when reviewing v2 I did try to make sure the documentation was of high quality but clearly I missed the mark. I will let you know once the MR improving documentation is up.

@sheaf

sheaf commented Jun 30, 2026

Copy link
Copy Markdown
Collaborator

I have put up semaphore-compat MR !11 with an overhaul of the documentation. I would appreciate if you could take a look and let me know whether it is sufficiently clear for your needs.

@sheaf

sheaf commented Jul 2, 2026

Copy link
Copy Markdown
Collaborator

I have put up semaphore-compat MR !11 with an overhaul of the documentation. I would appreciate if you could take a look and let me know whether it is sufficiently clear for your needs.

This has been merged and the documentation is available online on Hackage. Please let me know if there is anything else you would like to see documented.

This is follows GHC's dependency on `semaphore-compat-2.0.0` (first reflected in GHC 9.12.5-rc2).

The terminology of the dependency package now:
* introduces the concept of protocol versions for semaphores (there remains only one protocol version on Windows);
* distinguishes server semaphores and corresponding client semaphores; and
* distinguishes unversioned client semaphore names and client semaphore identifiers.

This conforms the language in Cabal's User Guide to that of the package.
@Bodigrim Bodigrim added merge me Tell Mergify Bot to merge and removed attention: needs-review labels Jul 5, 2026
@mergify mergify Bot added the ready and waiting Mergify is waiting out the cooldown period label Jul 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge me Tell Mergify Bot to merge ready and waiting Mergify is waiting out the cooldown period

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants