-
Notifications
You must be signed in to change notification settings - Fork 97
Write a cabal.project file in the benchmark example #640
Conversation
As suggested in #617. Taken fron haskell#624
Otherwise Cabal still errors out
Otherwise .hi and .hie files end up in different locations, which causes the getDefinition experiment to fail the second time it's run. This is because we assume in ghcide that .hi and .hie files have the same lifetimes, which is not true when the ..hie files are wiped but the .hi files aren't.
@@ -191,10 +190,10 @@ pattern IEThingAll a <- | |||
GHC.IEThingAll a | |||
#endif | |||
|
|||
setDefaultHieDir :: FilePath -> DynFlags -> DynFlags | |||
setDefaultHieDir _f d = | |||
setHieDir :: FilePath -> DynFlags -> DynFlags |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems unrelated. Is the goal here to separate it from the directory cabal uses? That seems sensible. Do you know why it was like this in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unrelated but in the same area (benchmarks). I added this fix to this PR to avoid starting a new one.
My thinking when I decided not to override the user setting was that .hie
files are independent of optimisation settings and therefore completely reusable across ghcide and cabal. This is still true, but as the commit message says, it turns out that ghcide makes assumptions about the lifetime of .hi
and .hie
files being the same, which is only true when they are both in a file system location under the control of ghcide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned in the commit message, this breaks the getDefinition experiment because the .hie
files live in the Cabal folder and get wiped across bench runs, whereas the hi
files live in the cache folder and survive across
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
* Write a cabal.project file As suggested in haskell/ghcide#617. Taken fron haskell/ghcide#624 * Write a cabal.project.local Otherwise Cabal still errors out * Override default hie dir Otherwise .hi and .hie files end up in different locations, which causes the getDefinition experiment to fail the second time it's run. This is because we assume in ghcide that .hi and .hie files have the same lifetimes, which is not true when the ..hie files are wiped but the .hi files aren't.
* Write a cabal.project file As suggested in haskell/ghcide#617. Taken fron haskell/ghcide#624 * Write a cabal.project.local Otherwise Cabal still errors out * Override default hie dir Otherwise .hi and .hie files end up in different locations, which causes the getDefinition experiment to fail the second time it's run. This is because we assume in ghcide that .hi and .hie files have the same lifetimes, which is not true when the ..hie files are wiped but the .hi files aren't.
* Write a cabal.project file As suggested in haskell/ghcide#617. Taken fron haskell/ghcide#624 * Write a cabal.project.local Otherwise Cabal still errors out * Override default hie dir Otherwise .hi and .hie files end up in different locations, which causes the getDefinition experiment to fail the second time it's run. This is because we assume in ghcide that .hi and .hie files have the same lifetimes, which is not true when the ..hie files are wiped but the .hi files aren't.
Extracted from #624 as this has started biting me too after upgrading cabal-install in my development environment