On 21.04.2010, at 12:45, Andy Stewart wrote: > Hi Axel, > > Axel Simon <axel.si...@in.tum.de> writes: > >> Dear all, >> >> the repo at code.haskell.org now contains a cabal version of Gtk2Hs, >> well, at least of the core packages glib, cairo, pango and gtk. In >> the >> future the package gio should be part of this set as well. All other >> add-on libraries, however, are likely to move into their own darcs >> repositories. > Does that mean we need move all packages (except glib, cairo, pango, > gio > gtk) to their own repositories?
Yes! > For example, do I need to create a new repository http://code.haskell.org/vte/ > after I finish conversion to Cabal? Yes. Maybe we can apply for these repositories all at once. >> During this transitional period it is not possible to >> build the other libraries but I encourage people to get the new cabal >> version using >> >> darcs get code.haskell.org:/srv/code/gtk2hs > Above command need password, should use below command: > darcs get --partial http://code.haskell.org/gtk2hs/ --old > Yes, true. Users without write access need to use the http: URL. I just tagged the repo with 0.10.5 and pushed this patch to the repo on my webpage containing the changes you made. >> >> and to add cabal files to the any of these add-on libraries. Notes on >> that below ("Creating a cabal file for a Gtk2Hs add-on library"). > I'm working on `vte`, `webkit` and `sourceview2`, i haven't test > code for > other packages, can you convert other packages? > > And we should drop > `gtk2hs/gtk/Graphics/UI/Gtk/TreeList` > and > `gtk2hs/sourceview`. > Above two packages is departed, haven't any reason to maintain them. > Yes, the first version of sourceview can probably go. >> >> Observe that updating your current darcs repo of the previous version >> of Gtk2Hs is not possible since I had to obliterate several patches >> in >> order to merge changes. Furthermore, there are quite a few patches in >> the previous repository that added a lot of new functions but which >> need further review. These patches have been merged into the new >> cabal >> version but for now remain in a separate repository which can be >> accessed at http://www2.in.tum.de/~simona/gtk2hs-2.18 . > I will correct those patches after i finish convert job. > BTW, i recommend we release next version after we finish Gtk+ 2.20 > binding. I think we should release as soon as all the cabal files and the new repositories are in place. The last release has been quite a while ago and people are waiting for a version that compiles with ghc 6.12. > And i'm waiting Ubuntu-10.04 release (April-29), then i can test Gtk > + 2.20, before > that, i will try to fix all bugs in Gtk+ 2.18.3 > I think conversion to Gtk+ 1.18 will take quite a bit longer. Mind you, you've done the merging but there are plenty of functions that need manual attention. I will of great help if you merge the simple functions that do not require any complicated memory management. However, it is important to bind only those functions that are useful. For instance, I've removed a couple of key-binding signals that cannot be used from within Gtk2Hs (at least not in the intended way). If you submit patches, please break them up into small pieces and leave all complicated functions in separate patches. >> >> Building >> -------- >> >> The Gtk2Hs libraries need additional build tools. These live in >> tools/ >> and can be configured and installed in the usual Cabal way. The three >> tools have awkward names starting with gtk2hs and are thus not likely >> to clash with other programs. If you install as --user, then you need >> to add ~/.cabal/bin to your path. (I've filed a bug that cabal should >> look in it's own /bin directory for build >> utilities. http://hackage.haskell.org/trac/hackage/ticket/663 >> ) >> >> When configuring the gtk package, the cabal file will look for Gtk+ >> 2.20 which you most likely don't have. You need to specify -f- >> gtk_2_20 >> for Gtk+ 2.18 and -f-gtk_2_20 -f-gtk_2_18 for Gtk+ 2.16 and so on. (I >> have filed a feature request that Cabal should be able to infer the >> best possible choice of flags for pkg-config >> requirements. http://hackage.haskell.org/trac/hackage/ticket/662 >> ) >> >> When compiling the Setup.hs program, you will see a warning that the >> Cabal version is guessed. If compilation succeeds, this warning can >> be >> ignored. (Cabal should really define CPP macros with it's version >> when >> it builds Setup.hs, see http://hackage.haskell.org/trac/hackage/ticket/326 >> ) > Excellent, installation is damn fast, i just need 5 minutes to build > gtk2hs. :) > > We should add `bootstrap.sh` similar with cabal-install's? > Then gtk2hs user just need *one* command to install all core > packages, and don't need > install those packages one by one. > My bootstrap.sh script would contain: for pkg in glib cairo pango gtk; do cd $pkg; cabal clean; cabal configure --user; cabal build; cabal haddock; cabal install; cd ..; done; We could add such a script for us but the ordinary user will hopefully get away with cabal-install. Cheers, Axel ------------------------------------------------------------------------------ _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
