Hi Ashish,
On Wed, Jan 06, 2010 at 12:02:33AM +0530, Ashish SHUKLA
Related to bsd.haskell.mk, I'm proposing to defer working on bsd.haskell.mk. But instead I want to propose something else, like Makefile.haskell which in concept is similar to Makefile.xpi and doesn't require fiddling with ${PORTSDIR}/Mk/bsd.port.mk files.
So Makefile.haskell shall take care of this by gathering all common definitions at one place, and then every port is only required to include Makefile.haskell like XPI ports do. I'll post an initial Makefile.haskell in a day or two. What do you think about this idea ?
I think this is a good idea. My first idea about bsd.haskell.mk was to put it into lang/ghc directory, but it exist a problem: this system isn't scalable. Actually you could have some problems with the expansion of some variables defined into a Mk/*.mk file.
In addition to that, I'm having a issue with latest haddock port with GHC 6.12.1. It depends on 'mtl' module which isn't provided by GHC anymore. So I created a port for 'mtl' and that port depends on 'haddock' for documentation generation. This is kind of circular dependency and can only be resolved if mtl is built with NOPORTDOCS flag set. So how is user going to build 'haddock' port, if mtl isn't installed and he doesn't have NOPORTDOCS set. Should 'haddock' port install 'mtl' port in SLAVE mode like GHC installs haddock and other ports. Or there is any other neat way of doing it ?
Yes, it exists a different way of doing it; that one I used for lang/ghc. An inplace installation of haddock into mtl/work directory, but I don't know if this is a neat way also for a simple port with a short time installation. Jacula Modyun