[Rant ahead...]
On Thu, Mar 31, 2011 at 11:33:39AM +0200, Jasper Lievisse Adriaanse wrote:
> > http://www.openbsd.org/faq/faq15.html#Latest
> It's more complicated then that in the case of ghc. Kili can elaborate more on
> that though..
>
> http://www.mail-archive.com/ports@openbsd.org/msg32063.html
>
> Bottom line is that the ghc teams breaks the ghc build system every full moon
> and there are some regressions in ghc-7 that need to be addressed first.
Oh, in this case (from 7,0.2rc back in december 2010 to 7.0.2 or
7.0.3), you could argue that it wasn't upstreams fault. All they
did was changing some make variables like INSTALL_PROGRAM,
INSTALL_SCRIPT, INSTALL_DATA, INSTALL_MAN from ordinary variables
to callable gmake macros, like in:
before:: INSTALL_MAN = $(INSTALL) -m 644
after: INSTALL_MAN = $(INSTALL) -m 644 $1 $2 $(call
MK_INSTALL_DEST,$3)
and at places where those variables are used:
before: $(INSTALL_MAN) $(INSTALL_OPTS) $(MAN_PATH)
"$(DESTDIR)$(mandir)/man$(MAN_SECTION)"
after: $(call
INSTALL_MAN,$(INSTALL_OPTS),$(MAN_PATH),"$(DESTDIR)$(mandir)/man$(MAN_SECTION)")
Now that's a valid change. However, our ghc port overrides those
variables to set permissions, owner and group to fit our needs. So,
technically our port caused the bteakage. But IMHO, make variables
like INSTALL_PROGRAM etc. are too generic to mutate them into gmake
macro definitions like the ghc folks did (for fixing yet another
obscure build problem on windows which I'm not even remotely intersted
in).
[Bonus rant, addressed to the OP}
Here are some operating system distributions providing ghc packages:
FreeBSD: 6.10.4
NetBSD: 6.8.3
OpenBSD: 6.12.3
Debian Squeeze: 6.12.1
Debian Sid: 7.0.2 <-- Use this -- if it's usable!
Gentoo: 6.12.3
Ciao,
Kili
