On Wed, May 11, 2011 at 6:13 PM, Gregory Crosswhite < gcross@phys.washington.edu> wrote: [snip]

1) Cabal is a tool that can only be used to build Haskell packages with some supporting C/C++ code thrown in

and

2) Cabal is currently the only tool that can realistically be used to properly build and install Haskell packages due to the great complexity involved with getting all the details right

I agree with much of what you said. I created this feature request for cabal, that I think would go quite aways towards addressing the problem, but someone marked it as wontfix: http://hackage.haskell.org/trac/hackage/ticket/815 In my opinion, the two most valuable things about cabal are its good dependency calculation and it allowed hackage to gain momentum. Unfortunately, we are also forced to use it as a build system and it's quite inadequate for that task. I say forced because there is no standard way to extract the dependency calculations from it. You have to write a Setup.hs file to extract it and it's not trivial. If you succeed at that task, then you can't even reuse the code without copy&pasting it later. In fact, I never invoke cabal-install directly anymore. I've corrupted my package databases too many times. I make sure to always use cabal-dev for everything. I think that says something about cabal's efficacy as a build system. Jason ps. As soon as I figure out a way to get infinite free time I'll implement the translation to makefiles myself...

On Fri, May 13, 2011 at 7:47 AM, Yves Parès wrote:

Talking about that, what are the differences between cabal-install and cabal-dev? Is cabal-dev (which I've never used nor installed) more suited for incremental development?

Cabal-dev is a wrapper around caba-install that primarily adds sandboxing but also adds support for loading your project into ghci. The sandboxing makes it possible to install multiple versions without disrupting other things. It gives you isolation so that if cabal-install overwrites a package it only affects your current build dir. I've completely stopped getting the diamond of death in my dependencies since I started using it. Someone made a great write up of how to get started with cabal-dev: http://www.reddit.com/r/haskell/comments/f3ykj/psa_use_cabaldev_to_solve_dep... It's actually very easy to get started with but extra documentation never hurts :) Jason

On Wed, 2011-05-11 at 18:13 -0700, Gregory Crosswhite wrote:

on top of it and have to start from scratch --- or worse, *autotools* (SHUDDER!)

While i don't have much experience autotools seems to be villainize. Sure it's old and have it's quirks. It is hard to learn and many people use it improperly. It have horrible libtool - but on the other hand it have many features that others had not in any sane manner (to mention one which is often neglected - parallel build). Regards

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

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

On Sun, May 15, 2011 at 8:21 AM, Malcolm Wallace wrote:

...

On 5/14/11 6:12 PM, Nathan Howell wrote:

...

Waf supports parallel builds and works with GHC without too much trouble.

I'm surprised no-one has yet mentioned Shake, a build tool/library written in Haskell.  It does parallel builds, multi-language working, accurate dependencies, etc etc.  I use it every day at work, and it is robust, scalable, and relatively easy to use.

I didn't realize Shake had been released! Thanks for pointing that out! --Rogan

Introductory video here:    http://vimeo.com/15465133

Open source implementation here:    https://github.com/batterseapower/openshake

Regards,    Malcolm

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Sun, May 15, 2011 at 8:21 AM, Malcolm Wallace wrote:

...

On 5/14/11 6:12 PM, Nathan Howell wrote:

...

Waf supports parallel builds and works with GHC without too much trouble.

I'm surprised no-one has yet mentioned Shake, a build tool/library written in Haskell.  It does parallel builds, multi-language working, accurate dependencies, etc etc.  I use it every day at work, and it is robust, scalable, and relatively easy to use.

It's not surprising if it's not public. No one is surprised that no one has mentioned the internal Google build system, for instance.

Open source implementation here:    https://github.com/batterseapower/openshake

It's good to see this, but is it usable yet? I was assuming from the fact that it's not on hackage yet that it's still experimental. If Shake is still "hopefully" going to be released then maybe there's not a lot of motivation to work on a replacement, but if it's in "no one knows" limbo then that could stall a replacement too. I don't really care so much about build systems that I'd write one from scratch or bootstrap an experiment, but if there were something that was already usable that would be a different story...