add --version-full and compiler info

[geekosaur]

I'm not sure if this counts as a significant change or not, since it's a new out-of-the-way command line option

hilfy «cabal+more-version-info¤@a11e10471» Z$ $(cabal list-bin cabal) --version-full
Warning: this is a debug build of cabal-install with assertions enabled.
cabal-install version 3.17.0.0 (commit 475bba6 on more-version-info, Wed Jan 21 01:42:37 2026 +0000)
compiled using version 3.17.0.0 of the Cabal library (in-tree)
with ghc 9.10.3 on linux x86_64

The information added by this change is the last line. If a development GHC version is used to build cabal, the version will include a datestamp (e.g. 9.14.0.20251128).

The original output of --version has been restored; all new information now lives under --version-full.

The reason for this is a perplexing cabal bug report on the FP Discord that turned out to be the user running a Linux build of cabal on FreeBSD. Cabal tends to trust System.Info for local system information for some things, but it's hardcoded to the system cabal was built on, not the one it's running on. (I think this can only arise on FreeBSD, although presumably a lesser form might happen on Apple Silicon Macs running an Intel build via Rosetta2.)

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

---

QA notes:

• Verify that --version is back to what it was before any of the git revision changes, including spaces
• Verify that --version-full includes git information (if supported) and compiler information
• Verify that cabal exec cabal -- act-as-setup -- --version-full includes git (if available) and compiler information
• If you're in a position to install the new Cabal library and have a Setup.hs sitting around, verify that runhaskell Setup.hs -- --version-full works and includes them
  • I'm not sure this is actually doable; can you force it to use a different Cabal than comes with the current ghc?
• If you happen to have a FreeBSD system, verify that
  • a native FreeBSD build has the correct information
  • a Linux build via the Linuxulator (if you have it configured) shows Linux information

[geekosaur]

This is a proposed change, and open to review and suggestions.

[Mikolaj]

LGTM

[ulysses4ever]

Can you show how it'll look like in the description? Also, it'd be good to add some motivation. Remember that by default we expect a ticket before a PR.

[geekosaur]

The motivation was trying to get that information from someone on Discord who was having odd problems with cabal, and IIRC it turned out they were using a cross-built cabal.

---

ETA: misremembered; they were using a Linux-built cabal on FreeBSD. As most OSes don't have built-in Linux emulators, this won't be common; the closest you'd get is Apple's Rosetta(2), which at least has the OS right.

I don't consider this final by any means; some programs have a --version-full option, for example, which includes this kind of information (and the GIT_REV stuff might also move there if we add it).

[geekosaur]

I moved that #if to a new Distribution.Client.Compat.SysInfo module.

[geekosaur]

Updated the title and description to reflect the new implementation.

[geekosaur]

Re-requesting reviews because adding a new option makes it a bit more invasive code-wise.

new code needs re-review

[geekosaur]

It just occurred to me: should the Cabal library get a similar change for Setup.hs's (Distribution.Simple, I presume?) CLI?

[Kleidukos]

On FreeBSD ✔️

$ cabal run -- cabal-install --version-full
cabal-install version 3.17.0.0 (commit a617480 on more-version-info, Tue Jan 20 22:49:20 2026 -0500)
compiled using version 3.17.0.0 of the Cabal library (in-tree)
with ghc 9.10.1 on freebsd x86_64

On Linux ✔️

$ cabal run -- cabal-install --version-full
cabal-install version 3.17.0.0 (commit a617480 on more-version-info, Tue Jan 20 22:49:20 2026 -0500)
compiled using version 3.17.0.0 of the Cabal library (in-tree)
with ghc 9.12.2 on linux x86_64

On FreeBSD with a statically-linked Linux binary

TBD (waiting for CI to produce the musl binary)

[Mikolaj]

It just occurred to me: should the Cabal library get a similar change for Setup.hs's (Distribution.Simple, I presume?) CLI?

Sounds potentially useful, e.g., for Linux distribution packagers.

[Mikolaj]

LEBTM

[Mikolaj]

Is this still relevant with this new setup and better backward compatibility?

[geekosaur]

Strictly speaking, adding a command line option is an interface change and should get a changelog entry.

[ulysses4ever]

@geekosaur I don't think Mikolaj doubts the need for changelog. I think he means the exact phrase about "relying on --version" that this comment is attached to. I agree that it looks outdated.

[geekosaur]

It's not really outdated, since such builds are already out there most likely. As such it's intended as a warning to anyone using such unreleased versions, which is part of the point of changelogs, no?

[geekosaur]

Back to draft until I can work on the Cabal part.

[geekosaur]

Okay, I think I have the Cabal part working now (including for build-type: Make despite the comment at the top saying "perhaps we should quit pretending this works"!).

[ulysses4ever]

Do we need to duplicate the whole logic in both Cabal and cabal-install? They will always be compiled by one compiler, right?

[geekosaur]

I was thinking about that when I added it to Cabal; it'd be pretty hard for them to differ, but I was copying logic in the other direction. cabal-install should probably reuse what I moved instead.