Skip to content

localPkgDescr is frequently out-of-date #3606

Open
@ezyang

Description

@ezyang

LocalBuildInfo has a localPkgDescr, so you might think that it would be OK to read out the PackageDescription from this rather than a PackageDescription that is passed into all of the main actions (e.g., build takes a PackageDescription as WELL as a LocalBuildInfo.) Well, that would be poorly assumed; a buildinfo hook can update the PackageDescription with extra information after the LocalBuildInfo has been built... meaning that the stored localPkgDescr 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 also updatePackageDescription; 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 wrong PackageDescription.

What's the moral of the story?

  1. DO NOT, I repeat, DO NOT use 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 of localPkgDescr more likely to work is, wherever we have a function that takes both a PackageDescription and a LocalBuildInfo, override the localPkgDescr right there.
  2. It really was a mistake to not apply hooked build info only once, at configure step. If we had done this, then it would not be necessary to repeatedly reapply the updates. Can we do this? I bet it will break client code too.

So there are three paths we can take.

  1. We can paper over this bug by updating LocalBuildInfo with an explicitly passed in PackageDescription so that the two are consistent.
  2. Going further, expunge all references to localPkgDescr in Cabal, such that it is ONLY used to reconstitute a PackageDescription at the very beginning. This could be done in combination with (1).
  3. Apply hooked build info at configure time, drop post-facto updates. Will probably break Setup code which is written to reapply the hooked build info at build/whatever time.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions