On Sat, Oct 20, 2007 at 03:25:04PM +0100, Duncan Coutts wrote:
On Fri, 2007-10-19 at 10:54 -0300, Isaac Dupree wrote:
How can user who does not modify Cabal file choose between all three of -O0, -O and -O2?
They cannot. Cabal currently only support a binary notion of optimisations. So it's either -O0 or -O.
As I understand, the Cabal developers claim that a user of an applied package p does not need to change anything in the file p.cabal. But there is a contradition here. For example, a user may need to build p via p.cabal under GHC and once under -Onot and next time under -O2. Suppose also that once the user needs to build p under -prof -auto-all and next time -- under -prof only. How can one do all this without intruding into p.cabal ? Personally, I would like better if the default for Cabal does not set any GHC options, and a user to be invited to edit the field `ghc-options:' in the .cabal file. This way, it looks simpler and less confusive. Regards, ----------------- Serge Mechveliani mechvel@botik.ru
On Sat, 2007-10-20 at 21:11 +0400, Serge D. Mechveliani wrote:
On Sat, Oct 20, 2007 at 03:25:04PM +0100, Duncan Coutts wrote:
On Fri, 2007-10-19 at 10:54 -0300, Isaac Dupree wrote:
How can user who does not modify Cabal file choose between all three of -O0, -O and -O2?
They cannot. Cabal currently only support a binary notion of optimisations. So it's either -O0 or -O.
As I understand, the Cabal developers claim that a user of an applied package p does not need to change anything in the file p.cabal.
That is the aim, yes.
But there is a contradition here. For example, a user may need to build p via p.cabal under GHC and once under -Onot and next time under -O2. Suppose also that once the user needs to build p under -prof -auto-all and next time -- under -prof only. How can one do all this without intruding into p.cabal ?
We don't claim that every possible ghc feature is exposed conveniently via Cabal. (If it were, there would be no point to having Cabal at all) So Cabal provides a way for users to choose between optimising or not, and building for profiling or not. The distinction between -O and -O2, and the distinction between -prof and -prof -auto-all is not something that Cabal exposes in a Haskell-implementation-independent way. If this is something that is vital for your users then there is the more general (but less convenient) Cabal configurations system. You can have flags which can be set by the user and you can define how the affect how your package is built. For example: flag optimise-more description: ... library ... if flag(optimise-more) ghc-options: -O2 jhc-options: ... Then you would tell your users to use an extra flag at configuration time: runghc Setup.hs configure -f optimise-more
Personally, I would like better if the default for Cabal does not set any GHC options, and a user to be invited to edit the field `ghc-options:' in the .cabal file. This way, it looks simpler and less confusive.
The problem with that is that it does not help make their packages portable between different Haskell implementations and it requires that all users know what the short cryptic ghc command line options mean. Editing a .cabal file is also something that does not make packaging convenient. For example how is a user of a rpm package, or someone using cabal-install supposed to specify these configuration options if they have to edit the .cabal file by hand? Duncan
participants (2)
-
Duncan Coutts -
Serge D. Mechveliani