Axel Simon <axel.si...@in.tum.de> writes: > 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. Okay, i see. > > >>> 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. Can't remove `TreeList` ? `ModeView` can replace it complete. Or you don't want break user's code? :)
> >>> >>> 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. Okay, i see. We release cabal files and don't wait Gtk+ 2.18 or Gtk+ 2.20 We add all new functions after release cabalized version. And good news is, current cabal packages works perfect 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. Okay, i will split current patches to *simple small patches* and *complicated functions*. I will ask your detail when i finish convert cabal. > >>> >>> 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. Nice. :) -- Andy ------------------------------------------------------------------------------ _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
