Configure/build separation

[Isaac Jones]

Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:

> 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.

We could possibly make cabal-setup/defaultMain be smarter and if you
tell it to build, check if it needs to be configured, and if so,
configure.  If you tell it to install, check if it needs to build and
do so.

>> > 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.

Remember that the configure step might call ./configure, which might
take lots of time.  Also, in order to be compatible w/ autoconf tools,
it's useful to have this separate step.

>> 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.

In any case, cabal-install will be a one-step tool, methinks.

> 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.

/me nods.

>> > 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.

I think adding tool dependencies is overkill, at least at the moment.
The only advantage would be so that we can give good error messages
when something that's actually required is not present.  It won't
significantly speed up the configure step.  Also, there's another
thread recently about this which I just posted to :)

peace,

  isaac