Thread: [wxhaskell-users] wxHaskell modularity

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi all,

I'm tearing my hair out trying to think of the best way forward for
modularizing parts of wxHaskell.

The problem currently shows itself mainly with STC, although over time
I'd expect to see this more often.

Currently, the build system works (hand-wavingly) as follows:

1) Build wxC wrapper for wxWidgets. Building this is really quite
dependent on how
   wxWidgets itself was built, which is OK on Unix (wx-config tells
you), but subject
   to much pain and guesswork on Windows.
   STC support is built at this time. If STC is not present in the
wxWidgets build,
   the wxSTC functions are all empty (but present).
2) Build wxdirect
3) Run wxdirect over wxC to generate Haskell bindings. This means that empty
    Haskell bindings are produced for the empty functions wrapping wxSTC (if it
    isn't built on wxWidgets).
4) Build and install wxcore
5) Build and install wx. This, again, contains hooks for the (possibly
not functional)
    STC.

This sort-of hangs together while we only have one 'contrib' module to
worry about, but it would become a maintenance nightmare if there were
ever to be more (of them (e.g. if I ever finish the build system, I'd
like to take a look at XRC support).

I'd prefer that there be an 'approved' way for people to add support
for additional wx functionalities without deep build system hacking.
The problem is that everything I think will mean considerable changes
to the way contributed modules are supported.

This is what I'm thinking:

Add a new 'contrib' directory for optional wxHaskell functionality.
This would contain one directory per contributed module.

Each contrib module would look something like the following:

module_name
|- Makefile
|--- wxc
|    |- Makefile
|    |- src
|    |- include
|
|--- wxcore
|    |- Makefile
|    |- src - Graphics - UI - WxCore
|
|--- wx
    |- Setup.hs
    |- module_name.cabal
    |- src - Graphics - UI - Wx

In the end, each contributed module would need to provide three
things: a C language wrapper for the wxWidgets functionality in
question (wxc); support for a basic Haskell wrapper over the C
(wxcore), and (optionally) a higher-level Haskell functional wrapper
(wx).

The build system would be more or less a plug-in template in each
case, with the contributor only needing to change the names of the
provided files.

The contributed module would appear as two Haskell modules, e.g.
WxSTCCore and WxSTC after installation.

I'd like to invite comments before I do all of this, as it's quite a
lot of work, and it will change a lot about the way STC (as the first
contrib module) is compiled. It will, however, mean that future
contributions will be easier as people would need only to work in a
single directory structure.

I think the only viable alternative is to very carefully and
explicitly state how wxWidgets must be built to support wxHaskell
(this would realistically mean only one supported configuration per
platform), and make *very* sure we provide binary installers for
wxWidgets with such a configuration as part of our distribution (note
that this would probably preclude Linux users from using the wxWidgets
provided by their package manager as the chances would be pretty high
that it would be incorrectly configured).

Regards
Jeremy

Thread: [wxhaskell-users] wxHaskell modularity

A Haskell binding to wxWidgets

wxhaskell-users