Comments on use of bsd.haskell.mk
Hi everyone,
Apologies for being unre{sponsive,achable} in the last few days.
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.
,---- Makefile
| PORTNAME= utf8-string
| PORTVERSION= 0.3.4
| CATEGORIES= devel haskell
| MASTER_SITES= ${MASTER_SITE_HACKAGE}
| PKGNAMEPREFIX= hs-
| PKGNAMESUFFIX= -ghc
|
| MAINTAINER= wahjava@gmail.com
| COMMENT= Support for reading/writing UTF8 strings for Haskell programs
|
| USE_CABAL= distrsimple:full docs hc:full lhs genreg profile:full
|
| .include
On Sat, Jan 31, 2009 at 11:15:50AM +0530, Ashish SHUKLA wrote:
Hi everyone,
[...]
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...?
Yes, this is the case. However, I am still working on some infrastructural things while juggling my busy semester. I will be committing this soon.
Thanks -- Ashish SHUKLA
Regards -- Samy Al Bahra [http://www.repnop.org/]
_______________________________________________ FreeBSD-haskell mailing list FreeBSD-haskell@haskell.org http://www.haskell.org/mailman/listinfo/freebsd-haskell
Hello Ashish, You wrote:
Apologies for being unre{sponsive,achable} in the last few days.
Anyway, you approved my port updates very quickly :)
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. [..]
Hm, your results seem to be promising! However, I would recommend you to use the D_NAME and D_NAME-VER plist_subs where applicable for the easier maintenance. It would be also nice to have a make(1) target (in bsd.haskell.mk) for generating pkg-plist files.
Now, I've a (C)omment, (Q)uestion and (S)uggestion regarding that bsd.haskell.mk w.r.t. to the above port stuff:
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 think we should agree on this. I do not have any objections, however until now, I have followed your ${PREFIX}/lib/${GHC_VER}/cabal solution :) I tried your converted utf8-string port, and I found that HsColour could use an automatic versioning scheme in the Mk file. (Because it refers to version 1.10, but now HsColour is at version 1.10.1, so this resulted an error.) Something like this: HSCOLOUR_VERSION?= `HsColour -version | cut -d ' ' -f2-` I am not sure whether it is a right thing, but it helped.
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). Okay, I will try to adapt some of my ports to this approach.
And until bsd.haskell.mk makes into the official ports tree, we should also keep porting new/updated ports in the current way. Although this will be a bit time consuming, but this will be helpful in testing bsd.haskell.mk and improving it wherever it lacks. And whenever bsd.haskell.mk goes into the tree, the haskell ports can also be submitted.
It might be worth a try at least.
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...?
I will contact the guy who submitted a port update for GHC about a month ago [1][2], maybe he could be also involved (and interested in it). Cheers, :g [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/130217 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/130218
Gabor PALI writes:
Hello Ashish,
Hi Gabor.
You wrote:
Apologies for being unre{sponsive,achable} in the last few days.
Anyway, you approved my port updates very quickly :)
Fortunately, I was submitting a new port when I recieved your PR :).
Hm, your results seem to be promising! However, I would recommend you to use the D_NAME and D_NAME-VER plist_subs where applicable for the easier maintenance.
I didn't get what you're trying to say. If you're talking about following line, then yes I should have used a variable there like %%D_LIBDIR_REL%%.
@dirrm lib/utf8-string-0.3.4
It would be also nice to have a make(1) target (in bsd.haskell.mk) for generating pkg-plist files.
Yes, a make target generating pkg-plist will be great idea. I think that is not just only useful for haskell[1]. BtW, is that even predictable prior to installation what files are going to be installed ? Although as of now documentation generated by the port is automatically tracked by bsd.haskell.mk. So no need to explicitly mention it in the pkg-plist.
Now, I've a (C)omment, (Q)uestion and (S)uggestion regarding that bsd.haskell.mk w.r.t. to the above port stuff:
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 think we should agree on this. I do not have any objections, however until now, I have followed your ${PREFIX}/lib/${GHC_VER}/cabal solution :) I tried your converted utf8-string port, and I found that HsColour could use an automatic versioning scheme in the Mk file. (Because it refers to version 1.10, but now HsColour is at version 1.10.1, so this resulted an error.) Something like this:
HSCOLOUR_VERSION?= `HsColour -version | cut -d ' ' -f2-`
I am not sure whether it is a right thing, but it helped.
There is a patch already present on that PR[2] which updates bsd.haskell.mk.
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). Okay, I will try to adapt some of my ports to this approach.
Cool, I will also try porting some of ports.
And until bsd.haskell.mk makes into the official ports tree, we should also keep porting new/updated ports in the current way. Although this will be a bit time consuming, but this will be helpful in testing bsd.haskell.mk and improving it wherever it lacks. And whenever bsd.haskell.mk goes into the tree, the haskell ports can also be submitted.
It might be worth a try at least.
Yes, that way we will be able to rectify and finetune the bsd.haskell.mk.
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...?
I will contact the guy who submitted a port update for GHC about a month ago [1][2], maybe he could be also involved (and interested in it).
Cool. References: [1] http://lists.freebsd.org/pipermail/freebsd-ports/2008-December/051708.html [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126012 -- Ashish SHUKLA
Hi,
Hm, your results seem to be promising! However, I would recommend you to use the D_NAME and D_NAME-VER plist_subs where applicable for the easier maintenance.
I didn't get what you're trying to say. If you're talking about following line, then yes I should have used a variable there like %%D_LIBDIR_REL%%.
@dirrm lib/utf8-string-0.3.4
Oh, sorry. I was thinking of the following (demonstrated by examples): %%D_LIBSUBDIR_REL%%/HSutf8-string-0.3.4.o -> %%D_LIBSUBDIR_REL%%/HS%%D_NAME-VER%%.o %%D_LIBSUBDIR_REL%%/libHSutf8-string-0.3.4.a -> %%D_LIBSUBDIR_REL%%/libHS%%D_NAME-VER%%.a %%PROFILE%%%%D_LIBSUBDIR_REL%%/libHSutf8-string-0.3.4_p.a %%PROFILE%%%%D_LIBSUBDIR_REL%%/libHS%%D_NAME-VER%%_p.a -> But they are just minor nits :)
[..] is that even predictable prior to installation what files are going to be installed ?
In my opinion, yes. I observed that files to be installed are usually placed in the ${WRKSRC}/dist/build directory. Of course, object files (*.o, but not in the root! -- eg. HSutf8-string-0.3.4.o) and the "autogen" directory should be omitted. By the way, there is another method for automatically generating packing lists, mentioned in the Porter's Handbook [1]. It is universal, but a bit complicated for me.
Although as of now documentation generated by the port is automatically tracked by bsd.haskell.mk. So no need to explicitly mention it in the pkg-plist.
Yes, and it is very nice. When I started to "improve PORTDOCS" in my recent port updates, I did almost the same: ports Makefiles have a clever machinery to automatically generating packing lists for PORT{DOCS,DATA,EXAMPLES}. [2]
HSCOLOUR_VERSION?= `HsColour -version | cut -d ' ' -f2-`
I am not sure whether it is a right thing, but it helped.
There is a patch already present on that PR[2] which updates bsd.haskell.mk.
Ooops :) Cheers, :g [1] http://www.freebsd.org/doc/en/books/porters-handbook/plist-autoplist.html [2] http://www.freebsd.org/doc/en/books/porters-handbook/install.html#INSTALL-DO...
Hi all,
I'm sorry if I sent my last message apart from this mailinglist, but its
attachments was too much heavy. I hope that you received it, otherwise I'll
send it again, and I'll reply also into the mailinglist.
On Mon, Feb 02, 2009 at 11:34:50AM +0530, Ashish SHUKLA
Gabor PALI writes:
It would be also nice to have a make(1) target (in bsd.haskell.mk) for generating pkg-plist files.
Yes, a make target generating pkg-plist will be great idea. I think that is not just only useful for haskell[1]. BtW, is that even predictable prior to installation what files are going to be installed ? Although as of now documentation generated by the port is automatically tracked by bsd.haskell.mk. So no need to explicitly mention it in the pkg-plist.
I think this is possible, but only for the "standard distributions", connecting this make target with the file ${PORTSDIR}/Tools/scripts/plist. I'll try <|%-). Jacula
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.
participants (4)
-
Gabor PALI -
Jacula Modyun -
Samy Al Bahra -
wahjava.ml＠gmail.com