
Jacula Modyun writes:
Hi Ashish,
On Wed, Jan 06, 2010 at 12:02:33AM +0530, Ashish SHUKLA
wrote:
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.
Thanks. I'm attaching a prototype Makefile.haskell (incomplete and completely GHC specific) which needs to be placed in ${PORTSDIR}/lang/ghc directory. I'm also attaching a Makefile of modified devel/hs-utf8-string-ghc port for this Makefile.haskell. The Makefile.haskell is not documented. If you guys like this idea and this prototype, then I suggest we work on it together and enhance it. We can get it committed as soon as we are done and it is also environment friendly (doesn't require a portbuild run :p). What say you ? I'm new to authoring such BSD Makefiles, please don't flame me :). But ofcourse point, where I can improvise. And if you guys are happy with the idea, we can host it on some public git repository, and start working on it.
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.
Sorry about that, I didn't noticed that we already have a port for mtl. Thanks to dezzy for reminding me that. I think we can solve this problem by creating a separate -docs port like we have for haddock, hscolour, etc. Ashish SHUKLA -- They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. -- Benjamin Franklin, Memoirs of the life and writings of Benjamin Franklin