Eric Kow <eric.kow@...> writes:

> May I ask which environment variables in particular you're referring to?

All of them, particularly those used to find the location of wxc. cabal-dev
installs all dependencies blindly, and doesn't know to set environment

> (B) [an aspiring wxHaskell hacker] modify wxcore's Setup.hs to use
> wxdirect as a library of some sort.  There's a bit of a complication
> here in that we're actually faking the dependency on wxdirect: we're
> claiming that wxcore depends on wxdirect when the case is more that
> the Setup.hs script used by wxcore uses wxdirect.

Removing this fake dependency would certainly help (also from wxc and
wxcore), because it messes up cabal-dev.

> - wxc (the C interface)

If I've understood you correctly, wxc doesn't install any Haskell libraries.
In which case, could it just create an executable that knows how to generate
the C wrapper? wxcore could then run it during setup, and finding it
wouldn't be a problem - cabal's bin directory is already on the path.

This might also make things easier for users of other languages wanting to
share wxc, as only template maniacs expect programs to do their work at
compile time :-)

My "vision", which may be fatally flawed for not understanding C, C++,
WxWidgets, or the WxHaskell build process, is:

 - cabal install wx-buildtools will install wxdirect (is this really needed
as a standalone executable?), and wxc, a program which knows how to create
the C wrappers. It will not install any libraries.

 - cabal install wxcore will run wxc to create the C wrappers, and put them
wherever it wants. It will not declare a dependency on wx-buildtools.

 - cabal install wx at it exist now.

Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
wxhaskell-devel mailing list

Reply via email to