OK, I'm studying http://www.haskell.org/haskellwiki/WxHaskell/Windows to update my understanding of the build infrastructure a bit
May I ask which environment variables in particular you're referring to? So for the matter of executables not being on the path, two approaches might be (A1) [the frustrated sandboxer] cabal-dev install wxdirect before cabal-dev install your-package. Whilst this would install wxdirect into your sandbox, with at least some versions of cabal-install, it also creates symlinks pointing from ~/.cabal/bin into said sandbox [fact-check?] (A2) [the frustrated sandboxer] like with gtk2hs, install wxdirect universally [I think this is what I do?] (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. There might be some unpredictable cabalisation problems that arise due to the current limitation I pointed to earlier https://github.com/haskell/cabal/issues/948 --- So we have: - wxWidgets C++ - wxc (the C interface) - wxcore (autogenerated Haskell [FFI stuff] + low-ish level Haskell calling the FFI stuff) - wx (nicer Haskell) In the case of wxc what we have are a bunch of C++ files that expose a C interface to wxWidgets. No fancy code generation, no Haskell. Sure there are folks who would love for wxc to be completely automatically generated (as would I), but nobody has gotten around to it. The wxc build script needs to know where WxWidgets lives so that it knows what libraries to link against (it calls the wx-config program for this, which alas doesn't really exist on Windows and you have to very painfully fetch a stand-in for), hence WXWIN The autogenerated parts of wxcore are I think Haskell wrappers around wxc [created by wxdirect]. The input to this process is just the handwritten wxc header files, which wxcore Setup finds by asking Cabal: https://github.com/atzedijkstra/wxHaskell/blob/master/wxcore/Setup.hs#L37 I notice that the wiki mentions WXC_VERSION and putting something like %CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% in the PATH. Yuck. This should “only” be needed when we actually want to run something, so that the Windows runtime linking stuff can do its magic with wxc.dll Once upon a time wxc/wxcore were a single package. And we relatively recently split them apart (I think to some rejoicing?) which made the wxcore build process a lot simpler (?). I'm afraid I'm going to have to put this down now so I can't research our decision to make the split, but I'd encourage anybody who wants to work on wxHaskell to study the evolution of this. Sorry for the mess folks! I think the build situation has improved a lot over the years. But we still have a way to go. I agree that fewer hoops and a one-shot install are important. Phew, hope this was useful. Hopefully I didn't get things wrong in my depiction above. I think my ideal situation would be for something like wxc to be shipped by default with wxWidgets and for a bunch of exotic languages to use the same layer. If you can make *that* happen by coordinating with various language teams like wxOCaml and with the wxWidgets folks, that'd be super. But it's a sort of long-term thing… (and may get bogged down by people hating the fact that wxc is handwritten when it can so clearly be autogenerated, but then nobody doing anything about it so it just gets stuck). So maybe the right thing to work on there is autogenerated wxc ;-) Eric On 31 May 2013 16:31, harry <volderm...@hotmail.com> wrote: > Eric Kow <eric.kow@...> writes: > >> Is the issue something related to the wxdirect executable not being >> available in the sandbox environment? > > Yes - executables built in cabal-dev aren't on the path (which is different > for each sandbox). If wxdirect only built an executable, I could install it > outside of the sandboxes, and it would be available in the path for later use. > > A similar issue arises with wxc - what exactly is it building, and why is an > environment variable needed to find it later? Is it creating a Haskell > library, or just creating come C files for use by wxcore? > > > ------------------------------------------------------------------------------ > 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. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > wxhaskell-devel mailing list > wxhaskell-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel -- Eric Kow <http://erickow.com> ------------------------------------------------------------------------------ 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. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
