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

Sat Jan 17 16:15:28 EST 2009

On Sat, Jan 17, 2009 at 01:08:16AM +0100, Gabor PALI <pgj at FreeBSD.org> wrote:

Hi all,

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

devel/hs-uuagc
devel/hs-uulib
graphics/hs-HGL-ghc
print/hs-hscolour
print/hs-hscolour-docs
x11-fonts/indic-ttf

I'd like to support this your initiative, because I use Haskell for my
studies and FreeBSD is the OS of my life. It is a long time that I'm
trying to make the Haskell ports system a better system for a developer :-), and
I have to thank Oliver Braun if it was possible for me to do these things as
a maintainer..
I'm started some month ago, introducing the possibility to compile the developer
documentation for every haskell ports with ghc.
Now I'd like to point out some question and answer, at the best of my
possibilities, to the questions that Gabor underlined.

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

	Ashish Shukla, Gabor Pali, Samy Al Bahra.
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.

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.

Then I want to answer to Gabor:

> Hi there,

Hi Gabor,

> 
> Since we have an own mailing list at last, I would like to raise some
> issues to be discussed.  I do not why, but I prefer e-mail over any
> other communication method, because it is stored (at several places)
> and I have time to process the input and produce the output :)  (And
> it also strikes a balance between the different time zones we live
> in.)  So, excuse me I am using this method, but I feel this the most
> "official" way to discuss any effort-related issue (but please, refute
> me if I am wrong...)

This is also my point of view; I prefer the mailing list and the e-mail over
any other communication method. It's very clean and mostly is for ever.

> Sorry in advance if I touch things those have been settled on IRC.  I
> think the problems and the decisions regarding them should be
> documented somehow, anyway.

Thank you for this your accuracy, only now I read all these things.

> 
> - Range of ports we maintain: In my opinion, it would be useful to
> identify which type of ports we maintain: in my first thoughts, it
> would be interesting to maintain GHC and libraries (mostly found on
> HackageDB [1]), but not complete applications (like Pandoc, that is
> also available via HackageDB, but it is a standalone application
> (however, it incorporates a library...) and it does not include the
> "hs-" prefix in its port name in the FreeBSD ports tree).  So, in
> brief: I suggest to add and maintain "hs-*" packages and lang/ghc.
> (More than enough :P)

This is, also for me, the best way to go. My interests are for the
infrastructure, WxHaskell and for the Haskell software related to:

Natural Language Processing
Dynamic epistemic logic
Theorem provers

> 
> - MAINTAINER field of the ports we maintain: To uniformize the effort,
> I suggest to set the maintainer all of the maintained ports to
> "freebsd-haskell at haskell.org" (address of this list), so any of the
> members could easily fix and add new ports, etc.  If somebody new
> wants to tackle these ports, he or she should contact us first and
> then delegate his or her patches though this list, and so on.

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.

> - Elimination of the "-ghc" suffix: Samy advised to get rid of those
> "-ghc" suffixes in the port names.  I asked haskell at freebsd.org guys
> about this suffix, and Volker told me that it was used to identify the
> ports that had been ported to GHC exactly.  Since GHC is the center of
> our efforts, I clearly agree with the elimination these suffixes.  (I
> do not whether it has been already done meanwhile, though.)  But we
> have to be careful with this, because many ports depend on hs- ports,
> so this kind of "refactorizaton" might result a huge patch (what it is
> not necessarily encouraged by FreeBSD porters)(?)
> 
> As a side note: packages with the "-ghc" suffix use a different
> destination directory, I hope you know this.  I think this should be
> also be unified.

About this I think that it's not so a good idea, at least at this moment.
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.

> - Composition of a "bsd.haskell.mk": It is a must, nobody can deny.

This was my first concern.

> In the first round, I do not think it should be placed right in the
> "ports/Mk" directory, because people at the BSD# Project [2] (I think
> I am going to refer them many times) store their own ".mk" file at the
> heart of their ports, lang/mono [3].  In my opinion, following this
> behavior would save the initial efforts from the burden of several
> port management tests and tasks ("experimental ports build" -- Mark
> Linimon mentioned these in the PR where a bsd.haskell.mk was offered
> [4]).  So, I suggest to add this file to the lang/ghc port first.
> 

Well this is a good point! :-) I developed the first bsd.haskell.mk and
the first bsd.wxhaskell.mk storing them at the heart of a given port, and
my first Pr for it was submitted with the intention to simplify my life:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/124047

but at the end I changed all and, even though I knew all about the burden of
several port management tests, I chose to place both the files in the port/Mk
directory:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126012

The reason is very simple. 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.

> About its structure: I suggest to employ some "build magic" to make
> its invocation automatic.  For example, every port with the "hs-"
> prefix (or in the "haskell" category) could automagically include this
> .mk file.  I do not think it would be hard to implement as this
> technique has been already used by bsd.xorg.mk [5] (e.g. around line
> 53).
> 
I'd have to study this solution, but I think that the advantages are
minimal.

> The actual structure of this file should be derived from the current
> hs-* ports -- I think it is easy, because many of these ports have a
> lot of constructs in common, so I would say (without experimenting
> with anything) their Makefiles could be even reduced to about 2-5
> lines(!) (including the port name and version, may be the
> dependencies) in an optimal case by a good .mk file. (But I am naive!
> :))  I think this approach could even make us re-think whether a
> cabal2port converter is really needed.
> 

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

> - Interference(?) with cabal-install: A few months ago, I created a
> preliminary port for cabal-install [6].  I think this or something
> like that should be added to our collection, so "the real bleeding
> edge" users do not have to wait for us with the ports.  It is okay,
> but it raises(?) an interesting problem: what if somebody starts to
> use both the ports _and_ cabal-install and even accidentally mixes
> them? (E.g. installs something with pkg_add then updates it from
> cabal-install or deletes it, and so on -- vice versa)  At the moment,
> I do not see any trivial solution to this problem, so any comments
> would be welcome.

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.

> - Merging our ports with the official FreeBSD ports tree:  port trees
> out of the official FreeBSD port tree (like KDE, GNOME, BSD# etc.) use
> different techniques to merge ("engraft") their trees.  Ashish
> mentioned that FreeBSD does not have a standard method for implemeting
> this when I mentioned the famous marcusmerge(8) [7] earlier.  He was
> not happy with this approach, but I found another meanwhile, called
> portshaker [8] (from BSD#).  I have not tried it yet, but it is a yet
> another way to solve this problem.

I have to see the portshaker solution, because I don't know it; I didn't
never use the mono infrastructure.

> - GHC 6.8.10:  What is up with GHC?  What are the exact obstacles to
> get the latest version ported? Has anybody tried it?  (I am just
> curious.)

During this month I'll take many tests at the University, but I'll try to
check if there are problems of compatibility.

Giuseppe Pilichi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/freebsd-haskell/attachments/20090117/28f73f49/attachment.bin