Comments (7)
I do think a solution that allowed for a user-supplied message would be nice. "Package not buildable in this environment, assertion failed: impl (ghc >= 7.0 && < 8.0)" is better, but "... 'foo does not support GHC 8.0 yet, see $link'" would be even better.
I also think it might be nice to allow this at the top-level somehow. It's usually the case that this stuff is all-or-nothing for a package.
from cabal.
For dealing with project P having package K compiling (or not) with GHC X, we're able to have per-GHC, Px projects1 (that exclude K if it doesn't build with X). Having per-GHC packages, Kx is unconventional (but actually doable2, if not in the same directory) but that got me thinking is there another option?
- Effectively embed multiple package configurations, each a K for X, in the one package by using
impl(ghc)
at the top-level.
Footnotes
-
Updo does this and uses a
ghc-x.y.z.*
naming convention for its ghc-prefixed-targets ↩ -
I haven't done this! I think it would be possible with
hpack-dhall
having done something similar varying packaging with sub-library granularity. Compare plugin-for-blobs/package.dhall that puts everything in one package to the other**/package.dhall
that create smaller packages. The reused configuration is in*.package-relative.dhall
files (dhall functions), such as plugin-for-blobs/uom/quantity/package-relative.dhall, that get imported and called. ↩
from cabal.
Projects only work if everything is in one repository. I want this to work even with published packages in a package repository like Hackage.
from cabal.
Projects only work if everything is in one repository.
Projects using source-repository-package
can work off-repository, can't they? I wonder if there's a cabal-testsuite/PackageTests
test for that?
from cabal.
I agree that this would be useful, and the buildable approach sounds good to me.
In #3072 is suggested an assert:
field with which the author also suggests we could assert a ghc version is within some bounds:
assert: impl(ghc >= 7.0 && < 8.0)
Coupled with good error messages printing the assertion, perhaps it would bring the resolution you seek without having to drop into the buildable
"low-level" detail.
from cabal.
I believe adding a message to buildable: false
(or equivalent) is the right way to do it.
If anybody wants to work on this I can advise/mentor.
from cabal.
I agree. I think that we should just start by attaching a message to buildable: false
constraints that morally works like "imprecise exceptions" and the message is derived from the surrounding conditional clause (if any) that guards the flag.
from cabal.
Related Issues (20)
- imported modules in cabal repl with multiple home units - very broken (?) HOT 3
- Wrong ghcversion.h file picked HOT 4
- PackageTests involving python deadlock in Windows CI HOT 1
- Generating PackageInfo_* files for dependencies to retire most usages of CPP. HOT 1
- Search does not Reveal Docs for `Paths_{pkgname}` HOT 5
- Regression in cabal-3.12.1.0: `cabal install --lib Adga` no longer works. HOT 8
- `cabal install` symlinks non-existing executables
- Cabal ignores buildinfo in top-level of directory HOT 7
- The solver should distinguish errors that are cause by the absence of a system libraries from other errors HOT 9
- Release checklist for 3.14.0.0 HOT 5
- Regression in HEAD leading to build path leaking into object files (preprocessors) HOT 6
- ghc-9.4+/Cabal-3.8+ continue to build package after source module files fail with errors HOT 2
- `cabal upload` throwing curl errors HOT 4
- `maintenance-depends` and a new `tool` selector for it HOT 5
- Changing a file imported by cabal.project does not trigger recompilation HOT 1
- Remove legacy code from code base HOT 3
- Reduce amount of CI round-tripping required by contributors HOT 3
- gen-bounds could use caret bounds and could be more concise HOT 1
- Structured hash tests are not invariant on GHC version
- Adopt cabal-add? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cabal.