
Hi all,
well, first of all I'm sorry for this long pause, but I'm very busy with my
university tests (my first semester is up to February the 18th), at the sec=
ond
I have to thank you, sincerely, for your confidence in admitting me into yo=
ur
developer team.=20
In any way I'd like to ask you (about Ashish I'll say below) if it's possib=
le to
have a your answer about the two questions, pointed out in my last last ema=
ils:
1) About the bsd.haskell.mk and bsd.wxhaskell.mk:
I'd like you could take in consideration my new proposal:
http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/126012
- the old is:
http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/124047
and could tell me if this proposal is good, in your opinion, interesting
and if you think that I have to work on it in the future or it is useless.
In the meantime I take my test, I'd like to read some opinion about
this solution for a future (after the 18th) work.
And, as pointed on to Gabor, I'd like some suggestion about my solution
regarding the documentation at the Pr:
http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/120975
Now.
On Sat, Jan 31, 2009 at 11:15:50AM +0530, Ashish SHUKLA
Anyways, I've *finally* gone through bsd.haskell.mk submitted by Jacula, and tried porting devel/hs-utf8-string-ghc to it and with little bit of struggle with documentation I was successful. Following are the Makefile and pkg-plist of the updated port.
This is great :-); I hope my code isn't too much boring and you enjoyed yourself a little with it. But I found some error in your USE_CABAL: USE_CABAL=3D distrsimple:full docs hc:full lhs genreg profile:full the correct one is: USE_CABAL=3D distrsimple:full docs hc:bothdep lhs profile:all:full 1) hc:full: the "full" flag isn't applied to the correct option group. You can: cd $PORTSDIR/devel/hs-utf8-string-ghc && make -DFUNKY_DEBUG_FULL funky or cd $PORTSDIR/devel/hs-utf8-string-ghc && make funky so your debug information: | =3D=3D=3D> hs-utf8-string-ghc-0.3.4 | =20 | funky: Options X Flags --> {defined,undefined}:(option,flag) |--> _optio= n_flag_ | :(option, ) |--> _optio= n__ | =20 | =20 | =20 | Options Flags Grues | =20 | (base , ) |--> _base__ . | (distrsimple , ) |--> _distrsimple__ . | (distrsimple , full ) |--> _distrsimple_full_ . | (docs , ) |--> _docs__ . | (genreg , ) |--> _genreg__ . | (haddock , ) |--> _haddock__ . | (hc , ) |--> _hc__ . | (hc , noargs ) |--> _hc_noargs_ . | (hc , nopath ) |--> _hc_nopath_ . | (hscolour , ) |--> _hscolour__ . | (lhs , ) |--> _lhs__ . | (profile , ) |--> _profile__ . | =20 | =3D defined | In USE_CABAL: | =20 | WARNING: | =20 | =20 | ERROR: | =20 | =3D=3D=3D> flag applied to the incorrect option group (full in hc:full) 2) genreg: the "genreg" flag is here useless, because this distribution generates its own register file register.sh and this flag allows you to generate this file for a distribution after its registration, using the command "ghc-pkg describe". 3) profile:full: it's better "profile:all:full", because the source code of this distribution hasn't any cost centres annotations, inserted by hand and this flag says "-auto-all" to ghc, so it can automatically insert a cost centre annotation around every top-level function. About this you could see the User's Guide of ghc 6.8.3 at: 6.1.1. Inserting cost centres by hand I'm sorry if I'm saying something of obvious to you. :-* 4) In my local port system I have the port converters/hs-utf8-string, that I use for the xmonad port installation, and my solution of putting this distribution into the "converters" category is inserted, like a suggestion, into the attachment hs-utf8-string-ghc.shar. What do you thi= nk about this my solution?
Q. As clear from the below output, the updated ports installs libraries in the ${PREFIX}/lib/${PORTNAME}-${PORTVERSION}/${GHC_VER} instead of the older ${PREFIX}/lib/${GHC_VER}/cabal. Is this convention going to be followed from now onwards, hmm... ? I'm a n00b in the Haskell world, so I'm not sure about this convention thingie, but anyhow package worked fine in that other location too, due to package registration script :).
Well the "cabal" directory is for the ghc specific libraries, dismembered by the ghc source code; for example because a more updated code exists in a separate repository.
C. The bsd.haskell.mk seems to be good enough, but few things I've not understood esp. the workings and theory of the "funky" part due to my lack of category-theory background. So pardon me for my n00bness atm but I'll try to understand this, as the theory part interests me too :). =20 This part is only a convenience of historical reference and it needn't understand or read it.
S. The best way to test out the bsd.haskell.mk is by porting more and more ports to it. So I recommend we should port existing ports and new ports to the bsd.haskell.mk way and push to the 'infrastructure' branch (or any other special branch created for the purpose). And until
And IIRC, Samy mentioned on the IRC that he is running GHC 6.10.1 on his "centrino" box. Samy if you need some testers, could you please push your port to the repo so we can start working with it. And also will I be able to install multiple versions of GHC side-by-side, hmm...?
If you think that this my solution (the file bsd.haskell.mk) is a good
solution, then I think that, when GHC 6.10.1 will work for FreeBSD, it
will be possible, for me and all you (I hope) to update this file and to
test it with many different ports. And in any way I hope this team is a
young baby with a promising future.
The attachments are:
- My version of the hs-utf8-string-ghc port.
- My two ports devel/hs-uulib, hs-uuagc in the bsd.haskell.mk version.
- A new port devel/hs-uuagc-prof; it installs the profiling version of the
command "uuagc": uuagc-prof.
Bye Jacula <|:-)
http://www.lefweb.uniss.it/index.php?sez=6&arg=6&txt=1&id=4820
P.S
I send my email mentioned at:
http://www.haskell.org/pipermail/freebsd-haskell/2009-February/000031.html
because in a private email:
On Wed, Feb 04, 2009 at 03:11:42AM +0530, Ashish SHUKLA
That defeats the purpose of the mailing list. Any discussions related to this topic needs to be on the list, will be helpful for someone trying to read the archives. BtW, in case your attachments are larger than the maximum allowed message size, then it will simply be rejected by the list server.