Configure/build separation

newer
darcs patch: Added c2hs dependency...

Neil Mitchell

17 Aug 2006 17 Aug '06

1:50 p.m.

Hi, First off, being a windows user, having a configure/build separation seems a bit unusual. However, accepting that separation has been chosen, I was wondering what the design rationale for the following behaviour is: I download alex from darcs, runhaskell Setup configure checks for an absolute pile of things - such as alex, c2hs, cpphs - all things that are absolutely not required. In amongst all this waffle, it also checks for Happy - an absolute essential build dependancy. It doesn't find that, like it doesn't find plenty of other things, and continues straight along. Then when I try to buid, it fails. So the two points are: 1) Shouldn't configure check for what is required, rather than everything that any Haskell program might possibly require. 2) Shouldn't failing a configure check be an error, directing you to go get happy? Thanks Neil PS. I'm really liking this Cabal thing, its a very nice concept.

Show replies by date

Duncan Coutts

17 Aug 17 Aug

2:29 p.m.

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. It's a distinction that an end user install tool like cabal-install doesn't need to make.

...

However, accepting that separation has been chosen, I was wondering what the design rationale for the following behaviour is:

I download alex from darcs, runhaskell Setup configure checks for an absolute pile of things - such as alex, c2hs, cpphs - all things that are absolutely not required.

I do not believe that was a deliberate design decision, but it was the quickest thing to code.

...

In amongst all this waffle, it also checks for Happy - an absolute essential build dependancy. It doesn't find that, like it doesn't find plenty of other things, and continues straight along. Then when I try to buid, it fails.

It would be great if it worked out what was needed and only checked for those, and then all failures could be reported.

...

So the two points are:

1) Shouldn't configure check for what is required, rather than everything that any Haskell program might possibly require.

2) Shouldn't failing a configure check be an error, directing you to go get happy?

Yes please. Send patches! :-)

...

PS. I'm really liking this Cabal thing, its a very nice concept.

Glad you've come round to the idea. :-) It really isn't an anti-windows conspiracy ;-) Duncan

Conrad Parker

18 Aug 18 Aug

2:20 a.m.

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 :)

...

...
In amongst all this waffle, it also checks for Happy - an absolute essential build dependancy. It doesn't find that, like it doesn't find plenty of other things, and continues straight along. Then when I try to buid, it fails.

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

Duncan Coutts

10:14 a.m.

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

Isaac Jones

20 Aug 20 Aug

11:31 p.m.

Duncan Coutts 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

Henning Thielemann

21 Aug 21 Aug

12:48 p.m.

On Thu, 17 Aug 2006, Duncan Coutts wrote:

...

On Thu, 2006-08-17 at 14:50 +0100, Neil Mitchell wrote:

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

It's even worse with generation of library documentation. You have to 'configure', 'build', and 'haddock' before 'install'.

Krasimir Angelov

12:55 p.m.

Since in Visual Studio there isn't a "Configure" command I decided to run configure automaticaly when the .cabal file is newer than .setup-config. The same trick can be used in cabal-setup. Cheers, Krasimir On 8/21/06, Henning Thielemann wrote:

...

On Thu, 17 Aug 2006, Duncan Coutts wrote:

...
On Thu, 2006-08-17 at 14:50 +0100, Neil Mitchell wrote:

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

It's even worse with generation of library documentation. You have to 'configure', 'build', and 'haddock' before 'install'. _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Isaac Jones

24 Aug 24 Aug

11 p.m.

"Krasimir Angelov" writes:

...

Since in Visual Studio there isn't a "Configure" command I decided to run configure automaticaly when the .cabal file is newer than .setup-config. The same trick can be used in cabal-setup.

Does anyone care to implement this kind of logic within cabal itself? Does anyone see anything wrong w/ it? peace, isaac

Simon Marlow

30 Aug 30 Aug

12:21 p.m.

Isaac Jones wrote:

...

"Krasimir Angelov" writes:

...
Since in Visual Studio there isn't a "Configure" command I decided to run configure automaticaly when the .cabal file is newer than .setup-config. The same trick can be used in cabal-setup.

Does anyone care to implement this kind of logic within cabal itself? Does anyone see anything wrong w/ it?

The issue is what to do about the arguments to configure. If we automatically configure, should it be done with no args? Or should we allow all the configure args to be given to the other commands? Personally I think we should punt on this, since cabal-install already does it and more. Cheers, Simon

6883

Age (days ago)

6896

Last active (days ago)

List overview

Download

8 comments

7 participants

participants (7)

Conrad Parker
Duncan Coutts
Henning Thielemann
Isaac Jones
Krasimir Angelov
Neil Mitchell
Simon Marlow

Configure/build separation

tags

participants (7)