[Freebsd-haskell] Some Topics to Discuss...

[Gabor PALI]

Hi Giuseppe,


Sorry for the late answer.


> I'm Giuseppe and I'm a contributor to FreeBSD ports:

Welcome!


> I'm started some month ago, introducing the possibility to compile the developer
> documentation for every haskell ports with ghc.

Would not be better to have these ports merged?  If I recall
correctly, Samy already said something like that on IRC a while ago.
However, it is a still an open question(?) what to do with libraries
and their documentation.  In ports of Ashish and mine, we respect the
NOPORTDOCS variable, so these ports could be installed with or without
documentation by setting this.


> Now I'd like to point out some question and answer, at the best of my
> possibilities, to the questions that Gabor underlined.

Thanks for the credit, but at the moment, I am only a doc committer
who is interested in using functional programming languages on
FreeBSD, and accidentally has (almost) direct access the ports tree :P


> 1) My first question is how I could become a named developer in this team
>   like the current developers:

I do not know who is maintaining the effort's web page, but I would
point to Samy.  He is the administrator here.  I do not have any
objection to include you.  The more developer we have, the more we can
progress.


> 2) I see that the git system was chosen; then which are the ideas about the future
>   structure of this repository and its maintenance, or committing policy.

Ashish already leaked a few lines about this to the mailing list: we
(are going to) have a master tree with the official ports, and a
haskell branch where the contributions can go.

I do not know about any (documented) committing policy, but it might
look like the following (feel free to criticize):
- work on the git repository,
- test its content on a tinderbox (even periodically, mainly on i386 and amd64),
- extract a patch for the official tree,
- submit a PR for the update in the official tree,
- get it reviewed,
- and finally commit.


> 3) My two primary interests are developing a bsd.haskell.mk file, with the
>   corresponding infrastructure and importing the WxHaskell libraries, and I
>   hope someone can help me in this work.

One of first our goals to establish such an .mk file, so you are not
alone at all :)


> Then I want to answer to Gabor:
[..]
> I haven't any important objection about this, but fixing the maintainer in
> this way reduces, for me, the level of responsibility and attention to
> each single haskell port.

I do not think you would be bored when we will have more than many
hundreds of hs-* ports :P


[..]
> Actually the haskell compilers are in development, and the ports with -ghc
> suffix are directly connected with the source of ghc and the ghc libraries.
> So, for me, it is better implementing a system turned towards the future,
> considering, at least, GHC Hugs nhc98 Yhc, and eventually also, if it needs,
> to keep more ghc versions in the port tree.

Well, that makes sense indeed.  By the way, I am getting afraid of GHC
6.10.x, since not all hackage builds with it currently (still).  I
think it would imply a separate port for the new GHC version.

Maybe we should offer more interfaces for Haskell ports (e.g. one for
cabal, one for hugs, and so on) in the bsd.haskell.mk.


[..]
> The major problem with bsd.port.mk,
> bsd.port.pre.mk, bsd.port.post.mk, bsd.port.options.mk and friends is
> the variable expansion. It's very hard to control the sequence of variable
> expansion and the flow of Makefile of a single haskell port, if the central file
> bsd.haskell.mk is stored in another directory that the ports/Mk one. You can
> check the differences between the two Prs above to understand this.
> Maintaining the first system is harder.

I thought of this just because BSDSharpers managed to solve these
problems somehow.  Okay, I will check out the referenced PRs.  Thank
you for pointing this out!

[..]
> My bsd.haskell.mk solution reduces the lines to about 5/10 (I tried with many
> different ports).

Hm, sounds interesting...


>> - Interference(?) with cabal-install [..]
> I don't think that it exists a simple solution, because the ports system is
> very tight about choices and frankly the majority of haskell software is in
> beta status, then It's better to have a single simple choice without mixing;
> and also the parsing is more complicated that a simple bsd.haskell.mk file.

Okay, let's ignore this issue for a while.


:g