For some projects, the overhead of building proper Haskell bindings is far greater than coding more in C++ and having a simple binding layer. The same goes for Scala and Python. We've been using Protocol Buffers as the common pickling engine, which alleviates us from porting everything (lots of libraries...) to Haskell. Similar enough to using JSON or XML to interop between Warp, Yesod, Happstack, etc... and a web client running javascript. I'm sure many of us would much rather code in Haskell everywhere but it's not practical all the time, at least not yet. Waf supports building code in dependent order, providing it knows about the dependencies. A simple regex based Haskell scanner does the job for me, describing dependencies within a single package. Cross package dependencies need to be explicit (as with cabal) because of overlapping/conflicting module names across packages. Overall it comes out to about 200 lines of Python, and does enough that I don't use cabal-install for my own projects. Building Haskell code in parallel with C++ can save quite a bit of time, and I personally don't enjoy waiting for unnecessarily serialized builds regardless of language. -n On Sat, May 14, 2011 at 8:54 PM, Gregory Crosswhite < gcross@phys.washington.edu> wrote:
What on earth are you doing that mixes Haskell, C++, Scala, and Python? I am very intrigued by the very idea of such a project. :-)
I have to confess that don't care for waf myself because I had unpleasant experiences using it which stemmed in part from its design which I also didn't like. For example, if you don't get the proper complex incantations correct then it will simply fail silently without giving you any hint as to what you might have gotten wrong, even for the most basic of tasks! Also, the last time I looked into waf in depth a couple of years ago the basic task model was designed around a language like C++ where there is a build phase and then a link phase and everything within a phase can be built in any order, so to compile something like Haskell code you need to essentially put every file in its own phase, but the scheduler they used for phases was not optimized at all precisely because they were assuming a C++-like model where there were only a couple of phases; they could have changed this since then, though.
But anyway, I am always willing to keep an open mind about tools if someone convinces me that my current negative impressions about them is wrong or outdated, so if you got waf to build a project with all four of those languages then that does definitely give it extra points in my book. :-)
Cheers, Greg
On 5/14/11 6:12 PM, Nathan Howell wrote:
Waf supports parallel builds and works with GHC without too much trouble. I use it in a mixed Haskell, C++, Scala and Python build. If there is interest I could conceivably clean up the ghc waf tool and release it.
On Sat, May 14, 2011 at 5:32 PM, Gregory Crosswhite < gcross@phys.washington.edu> wrote:
On 5/14/11 1:25 PM, Maciej Marcin Piechotka wrote:
(to mention one which is often neglected - parallel build).
While I do appreciate you stepping in to defend autotools (if for no other reason then because someone has to so that the discussion is balanced :-) ), I think that you are wrong to say that autotools is unusual in getting the idea of parallel builds right, since in my experience the opposite is the case: most systems support parallel builds --- such as SCons, CMake, I think waf, etc. --- with Cabal being an outlier here.
Cheers, Greg
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe