[Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13

[Yaakov Nemoy]

On Fri, Aug 22, 2008 at 3:53 AM, Jens Petersen <petersen at redhat.com> wrote:
> Hi Yaakov,
>
> Sorry for the slow response.  I was away last week.

Ditto.

>> * %buildsubdir is not a common way of doing things
>> ** we need this macro in the install phase to get at the working dir
>> we used to compile the package.
>
> This is not haskell specific and should really not be needed.
> Let's try to get rid of it.

It's needed for the macros that do file detection later on.  Once we
cd into the buildroot, we need a way of accessing the old dir we used
to compile the package.  Therefore, I've put it in a macro, and both
sets of macros are mandatory.  If you have a better solution, please
fix it.

> But how are packages supposed to get these macros?
> Surely each package is not going to include all of
> http://ynemoy.fedorapeople.org/haskell/macros.ghc ?

That file is going to be packaged with ghc itself.  I've submitted the
following bug.

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

> The macros are not really that ghc specific: they should be prefixed cabal
> not ghc.

Technically no, but I want to differentiate between what the
theoretical command might be for foo haskell compiler, and what
nuances there might be between compilers.

>
> IMHO some of it seems to be overkill.

How so?  For the most part, i'm converting the work that Bryan has
done into macros, and polished it up.  Every step that's there is
stuff that Bryan has decided is necessary.

> - if %ghc_autotools is necessary, can the -p option be made optional?

What should the default be?

> I attach an (untested) which cleans up the macro file a bit.

I've attached that to the bug report to add them to GHC.

>
>> * this file detection stuff is scary
>> ** I've put it into a series of macros and documented it
>
> Ok, that might be useful. :)
>
>> * this register stuff looks kinky
>> ** for starters, it's needed so the compiler knows where to look for
>> certain packages
>> ** it's been converted to a bunch of macros
>
> Less worried about that than I used to be.
> Again the macros don't really buy much.
>
> I don't quite understand %ghc_preinst_script and %ghc_postun_script: why do
> we need them?

Bryan answered this.

>
>> I also think that if we can make this any more simple, then the only
>> thing that cabal-rpm really really needs to do is detect if a package
>> is a library, binary, or both, and then fill in some of the
>> dependencies automatically, which it's not clever enough yet to do
>> properly anyways.  We may just need to create a few rpm templates, and
>> be done with it.
>
> Yes, maybe.
>
>> Anyways, I present the guidelines once more for review.  I will try to
>> comandeer the help of the people in the SIG to start putting together
>> a repo of packages using these macros.  The deadline for the F10
>> feature is coming up soon, and I want to have it in a relatively
>> stable shape, even though we have time to fine tune the details later.
>
> We really need to get some packages in the queue reviewed first to check the
> sanity of the draft.  And IMHO better to use KISS than too much
> overengineering.  We can add more macros if necessary after more experience
> at a later revision.

I have a couple of volunteers.  Gotta follow up on this.

-Yaakov