Configure/build separation

[Duncan Coutts]

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