From: Daan L. <daa...@xs...> - 2004-02-23 12:42:18
|
Announcement: wxHaskell version 0.6 ---------------------------------------------------------------------- <http://wxhaskell.sourceforge.net> This new release fixes many bugs, adds basic support for MDI applications and compiles with the latest CVS snapshots of wxWidgets. For now, only an installer for windows is provided. All the best, Daan. News (see the wxHaskell website for more information): - wxWindows is now called wxWidgets! (and yes, it is due to Microsoft :-) - wxWidgets runs on mobile phones (Symbian OS). - Borland Builder-X will ship with wxWidgets as its windowing toolkit. Updates: - Support for MDI applications - Combobox now catches enter keys through "on command" - Many list-like controls now react on "on select" instead of "on command" - Attribute "enable" is now called "enabled" - Resize bugs are fixed, new "dynamic" layout combinator added - Repaint bugs are fixed, new "fullRepaintOnResize" attribute added. - Basic support for unicode fonts (see the screenshots page) Tested on: - windowsXP and windows 2000 with ghc 6.2, 6.0.1, and wxMSW 2.4.2 - MacOS X 10.3 (Panther) with ghc 6.2 and wxMAC 2.5.1 (20 feb 2004) - MacOS X 10.2 (Jaguar) with ghc 6.0.1 and wxMAC 2.4.2 - Red Hat Linux 10 (Fedora) with ghc 6.2 - FreeBSD, with ghc 5.05.xxxx and wxGTK 2.4.1 - and wxHaskell has been known to run on other platforms :-) ---------------------------------------------------------------------- wxHaskell is a portable GUI library for Haskell. The goal of the project is to provide an industrial strength portable GUI library, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore build on top of wxWidgets -- a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge). Since most of the interface is automatically generated from the wxEiffel binding, the current release of wxHaskell already supports about 75% of the wxWindows functionality -- about 2900 methods in 500 classes with 1400 constant definitions. wxHaskell has been build with GHC 6.x on Windows, MacOS X and Unix systems with GTK. A binary distribution is available for Windows and MacOS X. And even if you don't intend to write GUI's yourself, it will be fun to check out the screenshots at <http://wxhaskell.sourceforge.net>. All the best, Daan Leijen. |
From: Axel S. <A....@ke...> - 2004-02-23 14:04:54
|
On Mon, Feb 23, 2004 at 01:33:38PM +0100, Daan Leijen wrote: > Announcement: wxHaskell version 0.6 > ---------------------------------------------------------------------- > Tested on: > - windowsXP and windows 2000 with ghc 6.2, 6.0.1, and wxMSW 2.4.2 > - MacOS X 10.3 (Panther) with ghc 6.2 and wxMAC 2.5.1 (20 feb 2004) > - MacOS X 10.2 (Jaguar) with ghc 6.0.1 and wxMAC 2.4.2 > - Red Hat Linux 10 (Fedora) with ghc 6.2 > - FreeBSD, with ghc 5.05.xxxx and wxGTK 2.4.1 > - and wxHaskell has been known to run on other platforms :-) It doesn't compile on Sun's Solaris. The linker falls over when building a shared library. Just in case anybody has succeeded in building on Solaris I'd like to know. Thanks, Axel. |
From: Gour <go...@ma...> - 2004-03-03 11:31:21
|
Daan Leijen (daa...@xs...) wrote: Hi Daan! > This new release fixes many bugs, adds basic support for MDI > applications and compiles with the latest CVS snapshots of wxWidgets. > For now, only an installer for windows is provided. Thank you very much for your cosntant work on wxHaskell. I hope in the future I'll find more time for wx(Haskell). At the moment I'm busys trying to build ghc-6.2 from the source on win98 (in MSYS env) since released version is not usable. (Again), I have one suggestion for wxHaskell: to combine doc & src packages into one - wxhaskell-x-xx. That will provide (easier) writing Gentoo ebuild and integration into official tree. (I'm sure it can be included - it's getting mature & regularly maintained). Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Matthew W. <ma...@al...> - 2004-03-03 11:42:57
|
Gour wrote: > Daan Leijen (daa...@xs...) wrote: > > Hi Daan! > > >>This new release fixes many bugs, adds basic support for MDI >>applications and compiles with the latest CVS snapshots of wxWidgets. >>For now, only an installer for windows is provided. > > > Thank you very much for your cosntant work on wxHaskell. I hope in the future > I'll find more time for wx(Haskell). At the moment I'm busys trying to > build ghc-6.2 from the source on win98 (in MSYS env) since released version > is not usable. > > (Again), I have one suggestion for wxHaskell: to combine doc & src packages > into one - wxhaskell-x-xx. That will provide (easier) writing Gentoo ebuild > and integration into official tree. (I'm sure it can be included - it's getting > mature & regularly maintained). Plenty of ebuilds seem to work from multiple source packages... I can't see a particular difficulty in writing one that installs wxHaskell source and documentation simultaneously. Although having said that, I can't get wxHaskell stuff to link properly on my Gentoo box at the moment, probably because my OpenGL setup is rather broken. |
From: Gour <go...@ma...> - 2004-03-03 12:11:42
|
Matthew Walton (ma...@al...) wrote: > Plenty of ebuilds seem to work from multiple source packages... I can't > see a particular difficulty in writing one that installs wxHaskell > source and documentation simultaneously. Thank you for pointing this out. I never came across one. I was playing during the 0.30.4 but could not solve sandbox problem since wxhaskell writes into /usr/lib. Of course, I did it with addwrite /usr/lib and some sed trickery (could not find haddock-base), but wanted to have more clean solution by patching Makefile. > > Although having said that, I can't get wxHaskell stuff to link properly > on my Gentoo box at the moment, probably because my OpenGL setup is > rather broken. Do you have some wxhaskell ebuild handy? Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Daan L. <daa...@xs...> - 2004-03-03 13:04:28
|
Dear Gour, On Wed, 3 Mar 2004 12:58:53 +0100, Gour <go...@ma...> wrote: > (Again), I have one suggestion for wxHaskell: to combine doc & src packages > into one - wxhaskell-x-xx. The documentation is generated from the source, so there is no need to include it. Furthermore, the binary releases include documentation nowadays. The doc package is just provided for those that don't have haddock or don't want to build the documentation themselves. > I was playing during the 0.30.4 but could not solve sandbox problem since > wxhaskell writes into /usr/lib. This is easily solved by giving the "--prefix" option to configure. See the "building" page on the wxHaskell website. (wxhaskell normally installs whereever you install wxWidgets). >> Although having said that, I can't get wxHaskell stuff to link properly >> on my Gentoo box at the moment, probably because my OpenGL setup is >> rather broken. You would only get openGL link errors if you build wxWidgets with "--with-glcanvas", leaving out that option will drop support of the openGL canvas and link properly. There also was a recent post on wxhaskell-users regarding openGL linking with more recent wxWidget versions that might solve your link problems too. Thanks for trying wxHaskell, Sincerely, Daan. ps. Let's take this discussion to "wxhaskell-users". |
From: Gour <go...@ma...> - 2004-03-03 14:04:56
|
Daan Leijen (daa...@xs...) wrote: > The documentation is generated from the source, so there is no need to > include it. > Furthermore, the binary releases include documentation nowadays. The doc > package > is just provided for those that don't have haddock or don't want to build > the > documentation themselves. Oops..excuse me. And, yes, I was thinking only about source package (not binary) release. > >I was playing during the 0.30.4 but could not solve sandbox problem since > >wxhaskell writes into /usr/lib. > > This is easily solved by giving the "--prefix" option to configure. See > the "building" page on the wxHaskell website. (wxhaskell normally installs > whereever you install wxWidgets). The point is that Gentoo has a concept of "safe sandbox" i.e. building process is done in temporary directory and if successful, it installs (emerges) into real directory. wxhaskell installs in /usr/bin (by default), so I had to add an option to allow wxhaskell ebuild to write directly into /usr/lib which is not safe in case something goes wrong since files in /usr/lib can be overwritten. I tried by patching configure & config/config.mk scripts to overcome LIBDIR entry. Now I am trying to build ghc-6.2 from source and/or waiting for official 6.2.1 since 6.2 is not usable. Then I'm going to resume Gentoo ebuild. > ps. Let's take this discussion to "wxhaskell-users". Yes. It was by mistaken cross-post. Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Daan L. <daa...@xs...> - 2004-03-03 14:24:35
|
Gour wrote: >> This is easily solved by giving the "--prefix" option to configure. See >> the "building" page on the wxHaskell website. (wxhaskell normally installs >> whereever you install wxWidgets). > > The point is that Gentoo has a concept of "safe sandbox" i.e. building process > is done in temporary directory and if successful, it installs (emerges) into > real directory. > > wxhaskell installs in /usr/bin (by default), so I had to add an option to allow > wxhaskell ebuild to write directly into /usr/lib which is not safe in case > something goes wrong since files in /usr/lib can be overwritten. > > I tried by patching configure & config/config.mk scripts to overcome LIBDIR > entry. You don't have to do that. If you give "--prefix" to configure it will work fine. You can also give "--libdir" explicitly. When you specify "--help" at the end of the options, you get a nice overview of all settings that will be used. All the best, Daan. ------------------------------------------------- > ./configure --prefix=/usr/sandbox --help usage: ./configure [options] options: [defaults in brackets] --help show this information --hc=<program> the haskell compiler [ghc] --hcpkg=<program> package compiler [ghc-pkg] --package-conf=<file> optional local package configuration [] --version=<version> library version [0.6] install options: --prefix=<dir> platform independent install directory [/usr/sandbox] <--- LOOK HERE --exec-prefix=<dir> platform dependent install directory [<prefix>] --libdir=<dir> library files install directory [<exec-prefix>/lib] <--- AND HERE --enable-strip remove symbols from the libraries [no] --enable-upx compress the dynamic libraries with upx [no] documentation options: --username=<name> username on sourceforge [dleijen] --haddock=<program> haddock documentation tool [haddock] wxwindows options: --wx-lib=<library> wxWindows library [/usr/local/lib/wx_base-2.5.dll] --wx-toolkit=<name> wxWindows gui toolkit [MSW] --wx-config=<program> wxWindows configure script (must be the first option!) [wx-config] platform options: --dllext=<extension> dynamic link library extension [.dll] --libprefix=<prefix> library prefix [] --extra-ld-opts=<opts> extra link options [] --with-msc compile wxWindows and wxc with microsoft vc++ [no] --wxc-libname=<name> wxc library name [wxc] |
From: Matthew W. <ma...@al...> - 2004-03-03 14:39:31
|
Daan Leijen wrote: > You don't have to do that. If you give "--prefix" to configure it will > work fine. > You can also give "--libdir" explicitly. When you specify "--help" at > the end of > the options, you get a nice overview of all settings that will be used. That works for some packages but we can never be sure it will work for all, because quite a few programs and libraries encode run-time paths in their binaries based on the settings of prefix and related such options given to configure. Because we ultimately want the build system to install it to a different place to the place it will actually be run in, that can cause serious problems. Can you guarantee that wxHaskell does not have any such compile-time-encoded paths in it? A common solution is an install target allowing specification of a target directory to be used instead of /. Thus you might invoke make DESTDIR="/var/lib/portage/work/wxHaskell-0.6.0/image/" install and Portage will copy that tree into / after the install's been determined to be successful. It also records files and mtimes and things at this point for uninstallation at a later date. I may be wrong, but I believe the GNU autotools make this kind of thing quite easy to do these days. |
From: Daan L. <daa...@xs...> - 2004-03-03 15:02:21
|
On Wed, 03 Mar 2004 14:26:00 +0000, Matthew Walton <ma...@al...> wrote: >> You don't have to do that. If you give "--prefix" to configure it will work fine. >> You can also give "--libdir" explicitly. When you specify "--help" at the end of >> the options, you get a nice overview of all settings that will be used. > > That works for some packages but we can never be sure it will work for all, because quite a few programs and libraries encode run-time paths in their binaries based on the settings of prefix and related such options given to configure. Because we ultimately want the build system to install it to a different place to the place it will actually be run in, that can cause serious problems. > > Can you guarantee that wxHaskell does not have any such compile-time-encoded paths in it? I can't guarantee it as I haven't tested myself on gentoo, but I believe that wxhaskell has no compile-time encoded paths in its generated libraries. During linking I use "--soname" to remove the directory part -- relying on the linker to find it (using LD_LIBRARY_PATH for example, or by putting it in the same directory as the executable, or ...) > A common solution is an install target allowing specification of a target directory to be used instead Good idea, maybe I'll make that an extra option if that proves useful for gentoo unix. Andres Loh is using Gentoo and he works just across my office so it would be relatively painless to do some testing :-) Thanks for the feedback, -- Daan. > I may be wrong, but I believe the GNU autotools make this kind of thing quite easy to do these days. I guess that is right, but the autotools gave me too much trouble to work across platforms (unix,win98,winXP,macOSX) and I dropped back to hand-written config/make -- and now that it is done, there is not much incentive anymore to do otherwise :-) |
From: Matthew W. <ma...@al...> - 2004-03-03 15:11:09
|
Daan Leijen wrote: > I can't guarantee it as I haven't tested myself on gentoo, but I believe > that wxhaskell has > no compile-time encoded paths in its generated libraries. During linking > I use "--soname" > to remove the directory part -- relying on the linker to find it (using > LD_LIBRARY_PATH for > example, or by putting it in the same directory as the executable, or ...) I'm not very big on the mysteries of linking and shared libraries and other such magic. I guess we could just try it and see :-) >> A common solution is an install target allowing specification of a >> target directory to be used instead > > > Good idea, maybe I'll make that an extra option if that proves useful > for gentoo unix. > Andres Loh is using Gentoo and he works just across my office so it > would be relatively > painless to do some testing :-) :-) >> I may be wrong, but I believe the GNU autotools make this kind of >> thing quite easy to do these days. > > > I guess that is right, but the autotools gave me too much trouble to > work across platforms (unix,win98,winXP,macOSX) and I dropped back to > hand-written config/make -- and now that it is done, there is not much > incentive anymore to do otherwise :-) Indeed. I personally dislike the autotools intensely, but sometimes they're the best available option. Clearly I think that indicates we need a new option. Thanks. Sorry if I'm coming over a bit abrupt, I'm writing these e-mails during compiles at work. |
From: Gour <go...@ma...> - 2004-03-03 16:26:46
|
Daan Leijen (daa...@xs...) wrote: > I can't guarantee it as I haven't tested myself on gentoo, but I believe that > wxhaskell has no compile-time encoded paths in its generated libraries. > During linking I use "--soname" to remove the directory part -- relying on > the linker to find it (using LD_LIBRARY_PATH for example, or by putting it in > the same directory as the executable, or ...) As I recall, (without using addwrite /usr/lib), the problem with just patching LIBDIR was that the package.conf file was messed up and after installation libraries could not be find when I tried some samples. However, I'm still green with the Haskell and ghc architecture, so I left things for the (better) future. otoh, wxhaskell is in a speed and my whxaskell build is still v0.3 :-( > Good idea, maybe I'll make that an extra option if that proves useful for > gentoo unix. Andres Loh is using Gentoo and he works just across my office > so it would be relatively painless to do some testing :-) > > Thanks for the feedback, -- Daan. Thank you for your presence. I can try next thing to write a new ebuild and do some testing. > I guess that is right, but the autotools gave me too much trouble to work > across platforms (unix,win98,winXP,macOSX) and I dropped back to hand-written > config/make -- and now that it is done, there is not much incentive anymore > to do otherwise :-) I understand you. Let's come together and write a decent Gentoo wxhaskell ebuild which can be submitted for inclusion! Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Daan L. <daa...@xs...> - 2004-04-01 08:28:17
|
On Thu, 1 Apr 2004 02:43:09 -0500, Dylan Thurston <dp...@pe...> wrote: > On Wed, Mar 03, 2004 at 01:50:58PM +0100, Daan Leijen wrote: >> >I was playing during the 0.30.4 but could not solve sandbox problem since >> >wxhaskell writes into /usr/lib. >> >> This is easily solved by giving the "--prefix" option to configure. See >> the "building" page on the wxHaskell website. (wxhaskell normally installs >> whereever you install wxWidgets). > > No, the wxhaskell install also writes to the GHC packages file, which > is at /usr/lib/ghc-6.2/package.conf on my system. You should use the "--package-conf" option to configure. Use "configure --help" to see all options. In general, to build locally, I use something like: > ./configure --prefix=~/local/wxhaskell --package-conf=~/packages Use "configure --help" to see all options. (Note that you can only use "~" with the latest cvs, use /home/name to circumvent this) If you also build wxWidgets locally: > ../configure --prefix=/home/daan/local/wxGTK-2.4.2 --disable-shared (Note "--disable-shared" is only recommended for the latest CVS version of wxhaskell (version 0.7)) Now, you can use for wxhaskell: > ./configure --wx-config=/home/daan/local/wxGTK-2.4.2/bin/wx-config --prefix=/home/daan/local/wxhaskell-gtk2.4.2 --package-conf=/home/daan/packages And than you can build multiple version next to each other (although you can only register one version with ghc each time). Note that you can use "make install", and "make uninstall" to test each version seperately. (with the latests CVS (version 0.7) the makefile knows about "DESTDIR", so you could sandbox that way too. There is also a "make install-files" that won't register the package. See "make help" for all targets.) All the best, Daan. Btw. I am currently in the process of releasing version 0.7, which will include rpm's this time :-) |
From: Matthew W. <ma...@al...> - 2004-03-03 13:34:02
|
Gour wrote: > Matthew Walton (ma...@al...) wrote: > > >>Plenty of ebuilds seem to work from multiple source packages... I can't >>see a particular difficulty in writing one that installs wxHaskell >>source and documentation simultaneously. > > > Thank you for pointing this out. I never came across one. You probably did, XFree86 uses several tarballs, although admittedly it does expand them all into the same place before building. There is though, as far as I can see, nothing to stop you making your own subdirectories of the build directory and extracting a tarball into each of those, then building and installing each of them as necessary. > I was playing during the 0.30.4 but could not solve sandbox problem since > wxhaskell writes into /usr/lib. > > Of course, I did it with addwrite /usr/lib and some sed trickery (could not > find haddock-base), but wanted to have more clean solution by patching Makefile. That would be preferable. An install target that supports DESTDIR is a nice preferable solution for most projects. Not necessarily the easiest to implement though, but it depends on the build system. >>Although having said that, I can't get wxHaskell stuff to link properly >>on my Gentoo box at the moment, probably because my OpenGL setup is >>rather broken. > > > Do you have some wxhaskell ebuild handy? No, I installed it by hand. I can have a go at writing an ebuild although if as you say wxHaskell writes into /usr/lib then a Makefile patch is probably in order. As I mentioned though, my wxHaskell is currently a bit broken so I'm going to have to sort that out first. Although I suspect the broken bit might actually be wxWidgets. |
From: Andres L. <kos...@ge...> - 2004-03-03 17:35:42
|
[rearranged the original message a bit] > >Do you have some wxhaskell ebuild handy? > > No, I installed it by hand. I can have a go at writing an ebuild > although if as you say wxHaskell writes into /usr/lib then a Makefile > patch is probably in order. As I mentioned though, my wxHaskell is > currently a bit broken so I'm going to have to sort that out first. > Although I suspect the broken bit might actually be wxWidgets. I have just committed a dev-haskell/wxhaskell-0.6 ebuild to the Gentoo CVS, so it should propagate within the next hour. I had it lying around for some time now, but never got around to actually adding it. It is tested on exactly one machine right now, but there seems to be request for it -- so please test and provide feedback, also if it works fine. > >Thank you for pointing this out. I never came across one. > > You probably did, XFree86 uses several tarballs, although admittedly it > does expand them all into the same place before building. There is > though, as far as I can see, nothing to stop you making your own > subdirectories of the build directory and extracting a tarball into each > of those, then building and installing each of them as necessary. You can just specify multiple URI's in SRC_URI, and all of them get downloaded and unpacked by default. As Daan pointed out, in the case of wxhaskell, it's not needed though, as the source distribution contains everything to build the documentation. > >I was playing during the 0.30.4 but could not solve sandbox problem since > >wxhaskell writes into /usr/lib. > > > >Of course, I did it with addwrite /usr/lib and some sed trickery (could > >not > >find haddock-base), but wanted to have more clean solution by patching > >Makefile. addwrite for the installation process is not an option. Usually, some combination of patching, setting prefix, or being lucky and have DESTDIR, helps. > That would be preferable. An install target that supports DESTDIR is a > nice preferable solution for most projects. Not necessarily the easiest > to implement though, but it depends on the build system. Should not be a problem. You could probably modify the Makefile and send the patch to Daan. I'm sure he will consider to apply it. > >>Although having said that, I can't get wxHaskell stuff to link properly > >>on my Gentoo box at the moment, probably because my OpenGL setup is > >>rather broken. I have added the library flags needed to link in the wx-gl libaries. I hope it actually still works with a non-opengl-enabled version of wxGTK, I haven't tried that. Best, Andres |
From: <wxh...@al...> - 2004-03-03 20:58:17
|
> I have added the library flags needed to link in the wx-gl libaries. > I hope it actually still works with a non-opengl-enabled version > of wxGTK, I haven't tried that. It does, I communicated this in private to Daan. "wx-config --gl-libs" on a non-OpenGL capable version of wxGTK returns the empty string. |
From: Gour <go...@ma...> - 2004-03-03 21:42:31
|
Andres Loeh (kos...@ge...) wrote: Hi Andres, > I have just committed a dev-haskell/wxhaskell-0.6 ebuild to the Gentoo > CVS, so it should propagate within the next hour. I had it lying > around for some time now, but never got around to actually adding it. > It is tested on exactly one machine right now, but there seems to be > request for it -- so please test and provide feedback, also if it works > fine. Just to report that your ebuild successsfuly emerged on my Gentoo box. So far I only tested it with HelloWorld.hs which gives: ./hello: error while loading shared libraries: libwxc-0.6.so: cannot open shared object file: No such file or directory (I'll try to debug it later.) Thank you very much for contributing (very educative) ebuild for wxhaskell. Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Andres L. <kos...@ge...> - 2004-03-03 22:49:52
|
> Just to report that your ebuild successsfuly emerged on my Gentoo box. > > So far I only tested it with HelloWorld.hs which gives: > > ./hello: error while loading shared libraries: libwxc-0.6.so: cannot open shared object file: No such file or directory > > (I'll try to debug it later.) I already noticed that. I have just fixed it (hopefully) in dev-haskell/wxhaskell-0.6-r1. > Thank you very much for contributing (very educative) ebuild for wxhaskell. You're welcome. Best, Andres |
From: Gour <go...@ma...> - 2004-03-04 08:39:30
|
Andres Loeh (kos...@ge...) wrote: > I already noticed that. I have just fixed it (hopefully) in > dev-haskell/wxhaskell-0.6-r1. Yup. This one works. Thanks. Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Jens P. <pet...@re...> - 2004-03-24 13:48:26
|
>>>>> "Daan" == Daan Leijen <daa...@xs...> writes: Daan> Announcement: wxHaskell version 0.6 I just uploaded a rpm package built for ghc-6.2.1 on Fedora Core 1 to: http://haskell.org/~petersen/rpms/wxhaskell/?C=M&O=D Jens |