-
Notifications
You must be signed in to change notification settings - Fork 698
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
localPkgDescr is frequently out-of-date #3606
Comments
/cc @dcoutts |
…#3606 Signed-off-by: Edward Z. Yang <[email protected]>
FWIW, I think this is the best (easiest to grok) option. It may break things, but at least they will be broken towards sensible. |
This implements the flag `--allow-older` which is the analogous to `--allow-newer` acting on lower bounds.
I just realized that this may not just double-apply, it may not apply at all. Here's a Setup script from
The modified hooked build info is only applied at build-time, not at configure time.
another from
Fortunately there are only a few dozen packages using Also it's embarrassing anyway because I broke |
I attempted (3) but I'm bailing, whoever decides to rewrite the hook interface should deal. |
LocalBuildInfo
has alocalPkgDescr
, so you might think that it would be OK to read out thePackageDescription
from this rather than aPackageDescription
that is passed into all of the main actions (e.g.,build
takes aPackageDescription
as WELL as aLocalBuildInfo
.) Well, that would be poorly assumed; abuildinfo
hook can update thePackageDescription
with extra information after theLocalBuildInfo
has been built... meaning that the storedlocalPkgDescr
may very well be out of date.So I wrote 30836c4 to make sure that we actually update
localPkgDescr
ourselves. BUT LITTLE DID I REALIZE that there are scads of code in the ecosystem which alsoupdatePackageDescription
; GHC is one of them! And in fact I spent most of this morning tracking down a bug whereby GHC's build system was silently dropping an extra library, because Cabal had been using the wrongPackageDescription
.What's the moral of the story?
localPkgDescr
. You CANNOT assume that it is up-to-date because client code may not have updated it while modifying the package description. I suppose something we could do which would make uses oflocalPkgDescr
more likely to work is, wherever we have a function that takes both aPackageDescription
and aLocalBuildInfo
, override thelocalPkgDescr
right there.So there are three paths we can take.
LocalBuildInfo
with an explicitly passed inPackageDescription
so that the two are consistent.localPkgDescr
in Cabal, such that it is ONLY used to reconstitute aPackageDescription
at the very beginning. This could be done in combination with (1).The text was updated successfully, but these errors were encountered: