Re: patch applied (cabal): add --enable-optimization/--disable-optimization config options (on by default)

On Sun, 2007-02-11 at 16:46 -0800, Ross Paterson wrote:
Sun Feb 11 16:45:13 PST 2007 Ross Paterson
* add --enable-optimization/--disable-optimization config options (on by default) M ./Distribution/Setup.hs +9 M ./Distribution/Simple/Configure.hs +1 M ./Distribution/Simple/GHC.hs +1 M ./Distribution/Simple/LocalBuildInfo.hs +1 M ./doc/Cabal.xml +18
This is great (I kept meaning to get round to it!) but I'm not sure it should be on by default. Certainly it should be used by cabal-install since that is a user tool for installing a package, but developers use the Seyup.hs or cabal-setup tools directly and they will not want -O to be on by default I think. If they were building it to install then they'd use the other tool, so if they're using the dev tool then it's likely because they want to do some development work and so will want a shorter build time. (Similarly, profiling is off for Setup.hs/cabal-setup but perhaps should be on by default for cabal-install) Am I wrong? What do other people reckon? Duncan

duncan.coutts:
On Sun, 2007-02-11 at 16:46 -0800, Ross Paterson wrote:
Sun Feb 11 16:45:13 PST 2007 Ross Paterson
* add --enable-optimization/--disable-optimization config options (on by default) M ./Distribution/Setup.hs +9 M ./Distribution/Simple/Configure.hs +1 M ./Distribution/Simple/GHC.hs +1 M ./Distribution/Simple/LocalBuildInfo.hs +1 M ./doc/Cabal.xml +18
This is great (I kept meaning to get round to it!) but I'm not sure it should be on by default. Certainly it should be used by cabal-install since that is a user tool for installing a package, but developers use the Seyup.hs or cabal-setup tools directly and they will not want -O to be on by default I think. If they were building it to install then they'd use the other tool, so if they're using the dev tool then it's likely because they want to do some development work and so will want a shorter build time.
I think developers can be expected to read the docs and turn off optimisations if they like. Everyone else should get -O by default, to avoid bad press ;-) it's easy enough for a developer to alias build="runhaskell Setup --disable-optimization" -- Don

On Tue, Feb 13, 2007 at 10:51:38AM +1100, Donald Bruce Stewart wrote:
I think developers can be expected to read the docs and turn off optimisations if they like. Everyone else should get -O by default, to avoid bad press ;-)
Since Duncan asked for opinions, I agree with Don. Thanks Ian

On Sun, 2007-02-18 at 17:18 +0000, Ian Lynagh wrote:
On Tue, Feb 13, 2007 at 10:51:38AM +1100, Donald Bruce Stewart wrote:
I think developers can be expected to read the docs and turn off optimisations if they like. Everyone else should get -O by default, to avoid bad press ;-)
Since Duncan asked for opinions, I agree with Don.
Ok, fair enough. Should --enable-optimisation also enable split-objs ? If --enable-optimisation is about building for installation then we'd want that too I'd assume. We've got a separate --enable/--disable flag for split-objs but perhaps the default for that flag should depend on the optimisation flag. Duncan

Ian Lynagh wrote:
On Tue, Feb 13, 2007 at 10:51:38AM +1100, Donald Bruce Stewart wrote:
I think developers can be expected to read the docs and turn off optimisations if they like. Everyone else should get -O by default, to avoid bad press ;-)
Since Duncan asked for opinions, I agree with Don.
Me too, and this corresponds with what GHC does: by default you get a fully optimised build, ready for installation. I think this is more or less standard practice, isn't it? Cheers, Simon
participants (4)
-
dons@cse.unsw.edu.au
-
Duncan Coutts
-
Ian Lynagh
-
Simon Marlow