[MacPorts] #48899: ghc & haskell-platform update?

[MacPorts]

#48899: ghc & haskell-platform update?
-----------------------------------+------------------------
  Reporter:  J.Gilbey@…            |      Owner:  neverpanic
      Type:  update                |     Status:  assigned
  Priority:  Normal                |  Milestone:
 Component:  ports                 |    Version:
Resolution:                        |   Keywords:
      Port:  haskell-platform ghc  |
-----------------------------------+------------------------

Comment (by mouse07410):

 > Sure, but given this argument, we might as well not package Haskell at
 all in MacPorts. We could just remove it and tell people to use the
 upstream binaries provided by the GHC developers

 That's what I wanted to do. It failed - see below.

 > > There already is Haskell Platform. The main reason I don't use it in
 its entirety is because it's GHC conflicts with Macports libiconv. So I
 had to rebuild GHC myself.
 >
 > Hm, that's weird. Binaries on macOS reference their libraries using
 absolute paths, and the upstream GHC binary shouldn't link against
 {{{/opt/local/lib/libiconv.2.dylib}}}, so unless you have
 {{{DYLD_LIBRARY_PATH}}} in your environment, the upstream Haskell Platform
 should just work. Have you looked into why that's not the case?

 Of course I did (see #57821). There are two reasons for this problem:
 - {{{libHSbase}}} exists only as {{{libHSbase.a}}}, so forget about
 absolute paths (the offending/offended library is static);
 - {{{libiconv.dylib}}} from Macports mangles function names, but preserves
 the same library name.

 > The benefit of having those [(presumably executable) tools] wrapped is
 that you have a single way to update them and a single interface to manage
 them. I don't want to have to care about five different language-specific
 package managers when all I want is a single end-user tool

 I don't see many Haskell-based tools that would qualify, and thus make
 what you describe worthwhile. But then, I cannot count myself as a
 significant contributor to Macports - so I defer to you here. Do as you
 see fit.

 > I agree there's not a big difference for somebody who develops in the
 Haskell ecosystem, but those people really don't need our help in figuring
 this out anyway

 Ideally, a developer would download {{{Haskell Platform}}} and go from
 there. Because that platform conflicts with Macports (see above), the
 options for the developer are to
 - replace Macports with Brew, which does not suffer from this problem;
 - rebuild GHC from sources to make it Macports-compatible (that's what I
 finally did, exhausting other options);
 - make Macports {{{libiconv.dylib}}} compatible - make a variant that
 doesn't mangle names (this request was shot down);
 - get Macports GHC (considering how old it is, and the likelihood that
 Macports-installed Haskell packages would conflict with the newer ones
 makes this completely unattractive).

 P.S. Factor in the fact that the current Haskell build tools ({{{cabal}}}
 and {{{stack}}}) are moving towards local snapshot-based approach - no
 global database of packages, registries at best per-user, or more likely -
 per-project. I don't see all the consequences of this, but it doesn't seem
 to play well with the Macports approach to global (per-machine) package
 repository.

-- 
Ticket URL: <https://trac.macports.org/ticket/48899#comment:46>
MacPorts <https://www.macports.org/>
Ports system for macOS