[MacPorts] #22387: pandoc build failure

[MacPorts]

#22387: pandoc build failure
---------------------------------+------------------------------------------
 Reporter:  dweber@…             |       Owner:  jgm@…           
     Type:  defect               |      Status:  new             
 Priority:  Normal               |   Milestone:                  
Component:  ports                |     Version:  1.8.1           
 Keywords:                       |        Port:  pandoc          
---------------------------------+------------------------------------------

Comment(by macports@…):

 I have to admit I was only trying it to get the "progit" book source
 turned into PDF - I would be seriously yak-shaving if that small task into
 maintainership of tools for a language I don't even know :-).

 That said, in a large sense the real problem to me seems to be that there
 are multiple delivery styles for the same language and it's libraries -
 there is the Haskell Platform .dmg, and a Haskell package manager internal
 to the language, and there is also the platform packaging system
 (macports).

 Without a huge injection of work to bring the macports style of Haskell
 installation up to date (platform is still on 2009-2-2! the libraries are
 aging etc) it seems like the best recommendation is to just mark the
 macports stuff deprecated and tell people honestly that for a good Haskell
 experience they should grab the Haskell platform .dmg, and use Cabal to
 internally manage Haskell libraries.

 I think that would solve the general Haskell ghc problem as it appears to
 be related to CPU exec protection features that have probably been solved
 in the year or two since the version of GHC in macports was released.

 CPAN, PEAR and rubygems all do the equivalent I believe - and the ones
 that do also have platform-native package system "mirrors" of their
 packages have only managed by coding up tools that take the language-
 native packaging and auto-generate platform-native packages from it. In
 that sense you'd need the Haskell Platform source code to have Portfile
 generation built in to it, and Cabal would have to be capable of
 generating Portfiles (or Makefiles) directly that would work - then the
 whole system could be in macports but with no special effort

 That has nothing to do with what anyone is asking :-), but I thought I'd
 mention it since I'd help package a bit perhaps but it just seems like a
 "try harder" strategy with this style as opposed to a "try smarter"
 strategy and I'd put money on anyone messing with a smaller-community
 language (like Haskell) is more of a "try smarter" type...

 Cheers!

-- 
Ticket URL: <http://trac.macports.org/ticket/22387#comment:8>
MacPorts <http://www.macports.org/>
Ports system for Mac OS