Hi Eric,
On 21/08/07, Eric Kow <[EMAIL PROTECTED]> wrote:
> Hi Jeremy,
>
> > (*) There's a secondary reason for factoring out the wxc build from
> > the wxHaskell build: a number of other languages (most of them in the
> > FP church, if you define it reasonably broadly) use wxC as the basis
> > fo
Hi Jeremy,
> (*) There's a secondary reason for factoring out the wxc build from
> the wxHaskell build: a number of other languages (most of them in the
> FP church, if you define it reasonably broadly) use wxC as the basis
> for their wxWidgets bindings.
Are you aware of the wxc project by any c
HI Shelarcy,
On 21/08/07, shelarcy <[EMAIL PROTECTED]> wrote:
>
> The problem is that we can't use nmake, because building on Windows
> deeply depends on Visual C++ project files.
I've actually already almost solved this.
I've factored out the wxc build from the top level makefile(*) and
made it
Hi Jeremy,
On Mon, 20 Aug 2007 23:48:38 +0900, Jeremy O'Donoghue <[EMAIL PROTECTED]> wrote:
> 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 guesswo
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 wrapp
