But haskellPackages are built with a specific version of GHC, aren’t they? I would say pretty much every package was buildable with at least one version of GHC when it was uploaded.
and why my current project run smoothly if it depends on some non-buildable packages?
It probably doesn’t depend on non-buildable packages.
Maybe. I’d be surprised, since you can depend on the ghc package in cabal files! The link you shared refers to base, not ghc, so I’m not really sure what you’re saying here.
If the source code was missing in the first place, how was ghc-9.2.8 built the first time?
I don’t know why you can’t build ghc-9.2.8 from the source distribution but this works, so it must be buildable in some form:
I think that Hackage only does some checks on the cabal file before you can upload a package. These checks correspond roughly to what cabal check does on the command line.
Hackage does have a builder which tries to build the package and upload the generated docs, but this build can fail. So, to my knowledge, Hackage does not prevent you from uploading packages which are completely unbuildable.
Adding build-matrices for every package on Hackage is probably unfeasible right now, but maybe Hackage could start displaying the tested-with field from cabal files. There would be no formal guarantee that the advertised GHC versions are actually tested and working, but it could encourage people to use this field. Flora.pm already displays this field, e.g in @hackage/prettyprinter
Once upon a time we had https://matrix.hackage.haskell.org/ which did a build of every hackage package, with all current compilers, and reported the results in a matrix.
Hmm, I found this Github discussion and this reddit thread. It is just a bit over a year that the builds are no longer running. From what I gather there, it doesn’t look completely impossible to get matrix builds running again.
Hackage is just a package dump. It does not enforce that packages are maintained, and since the break of matrix.hackage it cannot even tell whether packages still build.
Stackage selects (currently around 3000) packages from Hackage that are guaranteed to build and kept up-to-date. Any package can join Stackage as long as the maintainer is willing to do their job.
I recommend to limit dependencies to those that are on Stackage.
I don’t think anyone has explicitly said this yet: GHC itself—the Haskell compiler—is not buildable with cabal, and does not even really live on Hackage. There’s a ghc package, but unfortunately that’s not ghc-the-compiler and it’s mostly just there so you can browse the Haddocks for the internal libraries that you can access in your program when you compile it with GHC.
Although there’s a ton of Haskell inside GHC, it’s not really a “Haskell package” like everything else on Hackage. So that’s at least one package on Hackage that is not buildable.
This is definitely not the case; and I know because I myself have accidentally uploaded packages that are unbuildable (they could only be built with other dependencies fetched via stack, not cabal).
To be honest it’s a bit of an annoying situation, as oftentimes it’s not possible to get a buildable hackage package because of some stale dep that hasn’t been updated by the maintainer.
Probably this will become a bigger issue as time goes on and more projects go unmaintained.
good point. I think haskellPackages are automatically managed about callHaskellPackage, but which specific version of ghc the function invokes is out of my knowledge.
Intuitively this makes sense. However, when cabal build a brand new local project, assuming no local cache exist, cabal fetches all dependencies listed in .cabal from hackage and build locally, right? If there are no sufficient files for ghc-9.2.8 in the tarball file, how can cabal build locally?
The same error message, rejecting: ghc-9.6.2 (only already installed instances can be used) occurred to me, when i was trying to build ghc-9.6.2. The workaround still applies here. Im surprised that this didn’t happen to you.
I checked the source code for ghc-9.6.2. It clearly contains more source files than ghc-9.2.8, e.g. most *.h files are not presented in ghc-9.2.8.
any hints for fixing this error messages?
> cabal repl -w ghc-9.6.2 --build-depends='ghc==9.6.2'
Resolving dependencies...
Build profile: -w ghc-9.6.2 -O1
In order, the following will be built (use -v for more details):
- ghc-compiler-9.6.2 (first run)
Configuring ghc-compiler-9.6.2...
genprimopcode: readCreateProcess: posix_spawnp: does not exist (No such file or directory)
Error: cabal: Failed to build ghc-compiler-9.6.2. The failure occurred during
The ghc package is functional, we have a working prototype depends on it, calling runGhcT and doing program transformation stuff.
huh, i hope that’s not the case. using ghc-as-a-lib requires some functions that are not exported, i want to use some record functions such that i can peek into some data type and pretty print their value.
It just occurs to me, i can build ghc locally, exporting all the functions i need within. And build my project with it.
The same error message, rejecting: ghc-9.6.2 (only already installed instances can be used) occurred to me, when i was trying to build ghc-9.6.2. The workaround still applies here. Im surprised that this didn’t happen to you.
Ah, this is interesting! Perhaps this is because the ghc package very specifically exposes parts of GHC itself and therefore can’t be built separately from a binary build of GHC.
However, there will be very few packages of this nature. ghc-prim might be another, and the forthcoming ghc-internal and ghc-experimental.
There is a combinator called dontCheck which can be used to disable tests. As you can see, there are many packages for which tests have been disabled: configuration-common.nix
Exactly. It looks like a real package, but I don’t think you can download it from Hackage and use it independently. It walks like a duck and quacks like a duck, but it’s actually part of the GHC installation and there is no duck. To me that means it’s part of GHC and not a “buildable Hackage package” But maybe my definition is too narrow. After all, it is on Hackage and you can use it. You just have to use exactly the same one that’s installed with the GHC you happen to be using.
But maybe my definition is too narrow. After all, it is on Hackage and you can use it. You just have to use exactly the same one that’s installed with the GHC you happen to be using.