On Fri, 2006-08-18 at 12:20 +1000, Conrad Parker wrote:
On Thu, Aug 17, 2006 at 03:29:00PM +0100, Duncan Coutts wrote:
On Thu, 2006-08-17 at 14:50 +0100, Neil Mitchell wrote:
Hi,
First off, being a windows user, having a configure/build separation seems a bit unusual.
It's more for developers I'd say. It means you can configure once and then build, modify code, build, modify code etc etc without having to reconfigure each time.
That makes a lot of sense for (say) GNU autotools, where a fairly straightforward configure check for a few libraries can take a minute or so. With a faster configuration system (such as cabal), it may not be necessary.
I was very impressed with SCons when I ported some C code to use it rather than autotools -- the scons version configured and built (in one step, 'scons' with no arguments) in less time than autotools took to ./configure :)
Yes ./configure is very slow, but there is another reason too. runghc Setup.lhs configure --with-compiler=ghc-6.5.20060724 --with-hc-pkg=ghc-6.5.20060724 --enable-library-profiling I do not want to have to specify all that each time I build. With a configure/build split I specify it once and can then build many times.
It would be great if it worked out what was needed and only checked for those, and then all failures could be reported.
perhaps the developer could specify (in the .cabal file or so) which tools are actually required to build; I'm guessing this would require extra fields (not covered by build-depends or extensions). Perhaps something like build-tools or required-tools/optional-tools?
In most cases Cabal already knows which tools to use. The only time we might need a "build-tools" field is to specify that particular versions a required. Duncan