Opened 15 years ago
Closed 15 years ago
#19739 closed defect (fixed)
ghc: uses happy during configure
| Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | gwright@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.7.1 |
| Keywords: | Cc: | ||
| Port: | ghc |
Description
While configuring ghc @6.10.3_1 I got the happy error from #19737. This points out a problem: ghc should not be using happy at configure time, because ghc does not declare a dependency on happy. There is no way ghc could declare a dependency on happy, since happy declares a dependency on ghc, and circular dependencies are not allowed.
I was able to work around this by deactivating happy before trying to install ghc, but ghc should be fixed so this is not necessary.
Change History (4)
comment:1 follow-up: 2 Changed 15 years ago by gale@…
comment:2 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to gale@…:
GHC itself is written in Haskell. Every modern version of GHC requires a fairly recent previous version of itself to be already installed in order to compile. So this circularity is inherent to GHC, far beyond the issue with happy.
Well I know, but the ghc port does download a bootstrap version of ghc in order to compile the real version of ghc. So this is not at issue here.
It would be nice if the way that MacPorts deals with this issue were documented somewhere. If it already is documented, it would be nice if the port description for ghc would include a link to that page.
I'm not sure how much of this is documented, but ports cannot declare dependencies on themselves, it is not proper for a port to use a previous installed version of itself, it is not ok for a port to use software on which it does not declare a dependency, and there cannot be circular dependencies.
comment:3 Changed 15 years ago by gwright@…
| Status: | new → assigned |
|---|
Not a dependency issue, but likely (another) problem with the cabal version that ghc uses internally to build its libraries. It seems to test for the functioning of happy even if it is not required. Which triggers the happy bug noted in #19737.
comment:4 Changed 15 years ago by gwright@…
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
This should not occur anymore since #19737 is fixed.
However, there remains the upstream bug that cabal checks for functionality of all the tools it detects, even if they are not needed. If any of the tools are broken, cabal's configuration pass crashes.
Replying to ryandesign@…:
GHC itself is written in Haskell. Every modern version of GHC requires a fairly recent previous version of itself to be already installed in order to compile. So this circularity is inherent to GHC, far beyond the issue with happy.
There is a procedure for porting GHC to a new platform, but it is a long and complex procedure that requires significant manual human intervention.
It would be nice if the way that MacPorts deals with this issue were documented somewhere. If it already is documented, it would be nice if the port description for ghc would include a link to that page.