[Fedora-haskell-list] [Bug 460304] Add macros to GHC for packaging cabal packages for GHC

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=460304





--- Comment #12 from Yaakov Nemoy <loupgaroublond at gmail.com>  2008-09-04 23:11:23 EDT ---
Perhaps I should have been more specific.  Jen's macros call 'runhaskell'. 
This defaults to the default compiler on any given system. I would prefer we
deliberately called runghc.

Take the following case.  User A installs GHC and develops a package.  He posts
a spec for review.

User B prefers NHC and has it set up as his default compiler.  He downloads the
SRPM and builds it, which automatically gets built with NHC.  He then tests it
in mock, and it also works.  Mock used GHC.  Weird but ok.

User C uses Hugs98, and creates a second package.  He doesn't test it in mock,
because sometimes he's lazy.  User B downloads the SRPM and tries to build it. 
For some odd reason, hugs chokes on it.  Weird, and not ok.  Then for some
reason, the patch User B figures out makes GHC choke.  When the package is
compiled with mock, we have total failure.

This use case rubs against me the wrong way, because we used runhaskell instead
of runghc.

If we use runghc, then all three users will automatically use GHC, and
automatically be working on the same platform.  The package will then be named
ghc-* because it was tested on that.

When User B decides both packages should be done up in NHC, and User C decides
hugs98 suits him better, they both copy the macros file, patch the compiler
RPMs, and create nhc-* and hugs98-* variants.  The world is a happier place.

To make it absolutely clear, i'm not worried about the content of the macros. 
Jen clearly knows what works better than I.  I just think, that unless any
particular macro does not depend on the command 'runhaskell', namely can do
things exactly the same way, no matter which compiler is on the system, then we
can prefix it with  'cabal_'.  To the best of my knowledge, no macros meet
these requirements.  Likewise, the prefix 'haskell_' is also wrong.  I would
rather we stick to a consistent ghc- and ghc_ naming scheme.

On a side note, the packages I have submitted for review (the are blocked on
this bug, so you can find them through that reference) were built and tested
using my version.  Please be extra careful when testing them with Jens'
version.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.