wxhaskell-devel

[wxhaskell-devel] darcs patch: Remove support for GHC prior to 6.4. (and 3 more)

[Eric K. <eri...@gm...>]

I'm not sure if this really is working yet.

Notes:
-  this doesn't work with Cabal (unless you use --with-configure-opts) because
   the Make buildtype doesn't pass along the information we need (at least to
   my awareness).
-  I'm not particularly bothered if our implementation of this is ugly.  I
   figure that 0.11 is going to have wxc separated anyway, so maybe we'll be
   able to switch to Simple buildtype for wxcore and all this will be moot.
- The profiling version takes a ridiculously long time to link
- I haven't tried it out yet.

Mon Feb 25 22:35:54 GMT 2008  Eric Kow <eri...@gm...>
  * Remove support for GHC prior to 6.4.

Mon Feb 25 23:16:35 GMT 2008  Eric Kow <eri...@gm...>
  * Add wxcore-prof target for compiling profiling versions of wxcore.

Tue Feb 26 21:12:27 GMT 2008  Eric Kow <eri...@gm...>
  * Fix some bugs pointed out by shelarcy on wxcore-prof.

Tue Feb 26 21:51:55 GMT 2008  Eric Kow <eri...@gm...>
  * Add a configure option to enable wxcore profiling.

Re: [wxhaskell-devel] darcs patch: Remove support for GHC prior to 6.4. (and 3 more)

[shelarcy <she...@gm...>]

Hi Eric,

On Wed, 27 Feb 2008 06:55:48 +0900, Eric Kow <eri...@gm...> wrote:
> I'm not sure if this really is working yet.

You forgot to add installing phase for profiling library.
So I fixed that in attached profiling.dpatch file.

> Tue Feb 26 21:51:55 GMT 2008  Eric Kow <eri...@gm...>
>   * Add a configure option to enable wxcore profiling.
>
> (snip)
>
> hunk ./configure 343
> +      --with-hc=3D*)
> +	  hc=3D"$arg";;

Is this typo?
Do you want to write below code in this place?

        -with-hcprof|--with-hcprof)
	  enableprof="yes";;
        -with-hcpkg=*|--with-hcprof=*)
	  hcprof="$arg"
	  enableprof="yes";;

I don't fixed this part yet. Because I want to know what you intended.


> Notes:
> -  this doesn't work with Cabal (unless you use --with-configure-opts) because
>    the Make buildtype doesn't pass along the information we need (at least to
>    my awareness).

Okay, I know that.

> - I haven't tried it out yet.

I tried to use profiling library on Windows.

$ ghc --make STCEvent.hs -prof
$ STCEvent +RTS -p

Okay, profiling library works.
Attached archive is a report that was made by profiling library and RTS.


Best Regards,

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-devel] darcs patch: Remove support for GHC prior to 6.4. (and 3 more)

[Jeremy O'D. <je...@o-...>]

On Tue, 26 Feb 2008 13:55:48 -0800 (PST), "Eric Kow"
<eri...@gm...> said:
> -  I'm not particularly bothered if our implementation of this is ugly. 
>    I figure that 0.11 is going to have wxc separated anyway, so maybe 
>    we'll be able to switch to Simple buildtype for wxcore and all this 
>    will be moot.

I'm not sure. large parts of wxcore are generated by running wxdirect
over the wxc headers. I couldn't find a way to make cabal handle this
dependency without moving to the Makefile buildtype.

I actually got somewhat disillusioned with Cabal while trying to move
everything to using it because it really only knows about Haskell
dependencies and very simple C/C++ (i.e. which can be compiled via the
Haskell compiler). I haven't kept up well with the further development
of Cabal recently, but I suspect that the limitation probably remains.

The wxc separation should be OK - it's already (as noted previously)
essentially working for me.

Jeremy

Re: [wxhaskell-devel] darcs patch: Remove support for GHC prior to 6.4. (and 3 more)

[Eric K. <eri...@gm...>]

>  I'm not sure. large parts of wxcore are generated by running wxdirect
>  over the wxc headers. I couldn't find a way to make cabal handle this
>  dependency without moving to the Makefile buildtype.

Well, what I was hoping in my idealised vision of wxc separation was that
we could ship wxcore with all the auto-generated parts, leaving the
user with only Haskell modules to build.  The requirements then would
be for the user to have installed wxc already, much in the same way
that we already require that they install wxWidgets.  [My one worry is
how to make it so that when people use the wxcore package, the
necessary wxc stuff is linked in, but I'm guessing Cabal has a
mechanism for this]

For this to work, I'm guessing that your proposal for increased
modularity (wx-contribs/) would need to be implemented, so that we can
just distribute a bog-standard wxcore, and let people do their own
wxdirect on whatever extra modules they want.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9