Re: -O in 6.8.1-candidate
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. (Not knowing about profiling,) What if user wants to decide whether to use -auto-all? Somehow your answers don't seem to answer. Bear in mind that since Cabal is supposed to be portable it cannot translate every feature of every compiler. We decided initially that the notion of optimisation was important enough and supported by enough Haskell implementations to make sense supporting, but different levels of optimisation is getting quite compiler-specific. (some compilers may have idiosyncratic flags that USERS of THAT COMPILER want to choose for their own reasons) Which is why we have ghc-options, nhc98-options etc in the .cabal files. Now, IIRC cabal has something like a --ghc-option= flag that can be used in either configure or build, I can never remember which; and, if lucky, GHC has a way to override a prior -auto-all flag on the command line; -auto-all you, as user, may or may not have known was there. Right and we have a generic mechanism to pass any additional options to any program that Cabal knows about, like configure --ghc-option(s)= There is also the configurations system, so if your package needs extra nobs for a user to play with you can do exactly that: flag ricer description: compile with even more optimizations library ... if flag(ricer) ghc-options: -O2 -fgo-really-really-fast -funfolding-threshold=∞ Then all you have to tell the user has to do is: cabal-setup configure -f ricer On the issue of profiling with -auto-all I'm less clear about when that would be wanted. We have it off by default at the moment. Perhaps we can talk about what the default should be in various situations, and if it should be something that the user would want to turn on or off or if we can make a sensible decision automatically. This may be okay. The documentation should be clearer about this too, if so. Any specific suggestion? Or even better some text or a patch? Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
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. (Not knowing about profiling,) What if user wants to decide whether to use -auto-all? Somehow your answers don't seem to answer. Bear in mind that since Cabal is supposed to be portable it cannot translate every feature of every compiler. We decided initially that the notion of optimisation was important enough and supported by enough Haskell implementations to make sense supporting, but different levels of optimisation is getting quite compiler-specific. (some compilers may have idiosyncratic flags that USERS of THAT COMPILER want to choose for their own reasons) Which is why we have ghc-options, nhc98-options etc in the .cabal files. No, none of the above is true (or I miscommunicated) : they are supported in the following way of --programname-option. User is not supposed to (need to) modify .cabal file, nor be restricted to only issue commands that make sense on all implementations. Now, IIRC cabal has something like a --ghc-option= flag that can be used in either configure or build, I can never remember which; and, if lucky, GHC has a way to override a prior -auto-all flag on the command line; -auto-all you, as user, may or may not have known was there. Right and we have a generic mechanism to pass any additional options to any program that Cabal knows about, like configure --ghc-option(s)= I suppose cabal documents what programs it may use somewhere There is also the configurations system, so if your package needs extra nobs for a user to play with you can do exactly that: flag ricer description: compile with even more optimizations library ... if flag(ricer) ghc-options: -O2 -fgo-really-really-fast -funfolding-threshold=∞ Then all you have to tell the user has to do is: cabal-setup configure -f ricer That's interesting. It probably supercedes specific README instructions modify the cabal file in this or that particular way. (and user poking around can always still use --ghc-option or equivalently modify the .cabal file? after all why make a divide between users and devs?) This may be okay. The documentation should be clearer about this too, if so. Any specific suggestion? Or even better some text or a patch? check this for accuracy and appropriateness: Most of the time compiler-specific behavior isn't needed. Language extensions are specified with extensions:. When a package always should have a specific compiler flag with a specific compiler (for example, ---give a good example flag here---), this should go in fields like ghc-options: in the .cabal file. If the user of a package wants to customize how it's built with a particular compiler, they can use cabal's `configure --ghc-option=-Wall --ghc-option=-Werror`. If there is a particularly common customization such that the package developer wants to support an easy choice by the users, see the configurations flag system section. What flags are known to be used compiler-specific? Each appropriateness could be discussed specifically of course. -O2 -Wall, and other GHC warning-flags -auto-all others? what Hugs or other impls' flags are used? Isaac ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
On Sat, 2007-10-20 at 11:13 -0400, Isaac Dupree wrote: Duncan Coutts wrote: Which is why we have ghc-options, nhc98-options etc in the .cabal files. No, none of the above is true (or I miscommunicated) : they are supported in the following way of --programname-option. User is not supposed to (need to) modify .cabal file, nor be restricted to only issue commands that make sense on all implementations. Right, we have ghc-options: in the .cabal file for developers and cabal-setup configure --ghc-options= for users/packagers/distributors. Now, IIRC cabal has something like a --ghc-option= flag that can be used in either configure or build, I can never remember which; and, if lucky, GHC has a way to override a prior -auto-all flag on the command line; -auto-all you, as user, may or may not have known was there. Right and we have a generic mechanism to pass any additional options to any program that Cabal knows about, like configure --ghc-option(s)= I suppose cabal documents what programs it may use somewhere Yes, cabal-setup configure --help lists all the programs that the flags --with-$PROG= and --$PROG-option(s)= apply to. The set of programs is not fixed as it can be extended by the Setup.hs file. I'm not sure if this is well documented in the user guide. Documentation patches are always gladly accepted. There is also the configurations system, so if your package needs extra nobs for a user to play with you can do exactly that: flag ricer description: compile with even more optimizations library ... if flag(ricer) ghc-options: -O2 -fgo-really-really-fast -funfolding-threshold=∞ Then all you have to tell the user has to do is: cabal-setup configure -f ricer That's interesting. It probably supercedes specific README instructions modify the cabal file in this or that particular way. (and user poking around can always still use --ghc-option or equivalently modify the .cabal file? Right. after all why make a divide between users and devs?) Because they have different intentions and levels of knowledge about the tools. This may be okay. The documentation should be clearer about this too, if so. Any specific suggestion? Or even better some text or a patch? check this for accuracy and appropriateness: Most of the time compiler-specific behavior isn't needed. Language extensions are specified with extensions:. When a package always should have a specific compiler flag with a specific compiler (for example, ---give a good example flag here---), this should go in fields like ghc-options: in the .cabal file. If the user of a package wants to customize how it's built with a particular compiler, they can use cabal's `configure --ghc-option=-Wall --ghc-option=-Werror`. If there is a particularly common customization such that the package developer wants to support an easy choice by the users, see the configurations flag system section. Perhaps this could be integrated into the new introduction I posted for review the other day: http://haskell.org/pipermail/glasgow-haskell-bugs/2007-October/010388.html What flags are known to be used compiler-specific? Each appropriateness could be discussed specifically of course. -O2 -Wall, and other GHC warning-flags -auto-all others? what Hugs or other impls' flags are used? You mean what flags are commonly used in compiler-specific options fields that are not currently covered by generic Cabal features like --enable-optimzation etc? The most common ones I see probably are -Wall and other specific warning flags, -O2. Some packages specify things like ghc-options: -DFOO=BAR but that's now covered by the portable cpp-options: field. Some use ghc-options: -fglasgow-exts because they only use extensions when they're using ghc and otherwise use portable code. This could be replaced with the clearer: if impl(ghc) extensions: Blah As I said, I'm not sure about -auto-all. I've not seen any packages use that before, except docon. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -O in 6.8.1-candidate
On Fri, 2007-10-19 at 10:42 +0100, Simon Peyton-Jones wrote: | In general the users should never have to modify the .cabal file. For | the common settings that we expect the user to want to control Cabal | provides configure flags. | | The idea is that instead of having to find the options for each | implementation you might want to use, that Cabal knows the right options | for each compiler to use a feature like optimisation or profiling or | whatever. You have a clear mental model of how Cabal is intended to be used -- although it also provides trapdoors (like ghc-options) for when the intended path isn't adequate. But that mental model is much clearer to you and the other Cabal developers than it is to Cabal users like Serge and me. Would it be worth writing a new section in the Cabal manual that describes the intended use model for Cabal, for the benefit of Cabal users? That way you'd be able to explain this stuff once and for all. Documentation often focuses on the knobs (turn the steering wheel to make the car change direction), and omit the larger mental model of what is going on (cars should be driven on a road). Yes. Here's a new introduction for the user's guide. Comments and improvements welcome. Duncan sect1 id=intro titleIntroduction/title para Developers write Cabal packages. These can be for libraries or executables. This involves writing the code obviously and also creating a literal.cabal/literal file. The .cabal file contains some information about the package. Some of this information is needed to actually build the package and some is just useful for identifying the package when it comes to distribution. /para programlisting name: Foo version: 1.0 library build-depends: base exposed-modules: Foo /programlisting para Users install Cabal packages so they can use them. It is not expected that users will have to modify any of the information in the literal.cabal/literal file. Cabal does provide a number of ways for a user to customise how and where a package is installed. They can decide where a package will be installed, which Haskell implementation to use and whether to build optimised code or build with the ability to profile code. /para programlisting tar -xzf Foo-1.0.tar.gz cd Foo-1.0 cabal-setup configure --with-compiler=ghc-6.4.2 --prefix=$HOME --user cabal-setup build cabal-setup install /programlisting para One of the purposes of Cabal is to make it easier to build a package with different Haskell implementations. So it provides abstractions of features present in different Haskell implementations and wherever possible it is best to take advantage of these to increase portability. Where necessary however it is possible to use specific features of specific implementations. For example one of the pieces of information a package author can put in the package's literal.cabal/literal file is what language extensions the code uses. This is far preferable to specifying flags for a specific compiler as it allows Cabal to pick the right flags for the Haskell implementation that the user picks. It also allows Cabal to figure out if the language extension is even supported by the Haskell implementation that the user picks. Where compiler-specific options are needed however, there is an escape hatch available. The developer can specify implementation-specific options and more generally there is a configuration mechanism to customise many aspects of how a package is built depending on the Haskell implementation, the Operating system, computer architecture and user-specified configuration flags. /para programlisting name: Foo version: 1.0 library build-depends: base exposed-modules: Foo extensions:ForeignFunctionInterface ghc-options: -Wall nhc98-options: -K4m if os(windows) build-depends: Win32 /programlisting /sect1 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
defines, for example, whether to compile the library with -O, with -O2, or with -Onot. The meaning of these options is explained in the GHC documentation. Ok, so you can get rid of -O and -prof and instead use: runghc Setup.hs configure with our without the following options: --enable/disable-optimization (default is enabled) --enable/disable-library-profiling (default is disabled) The option -auto-all is not the default for Cabal's --enable-library-profiling but you can make it so using: ghc-prof-options: -auto-all and this option will only be used when the user configures with --enable-library-profiling How can user who does not modify Cabal file choose between all three of -O0, -O and -O2? (Not knowing about profiling,) What if user wants to decide whether to use -auto-all? Somehow your answers don't seem to answer. (some compilers may have idiosyncratic flags that USERS of THAT COMPILER want to choose for their own reasons) Now, IIRC cabal has something like a --ghc-option= flag that can be used in either configure or build, I can never remember which; and, if lucky, GHC has a way to override a prior -auto-all flag on the command line; -auto-all you, as user, may or may not have known was there. This may be okay. The documentation should be clearer about this too, if so. Isaac ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -O in 6.8.1-candidate
| In general the users should never have to modify the .cabal file. For | the common settings that we expect the user to want to control Cabal | provides configure flags. | | The idea is that instead of having to find the options for each | implementation you might want to use, that Cabal knows the right options | for each compiler to use a feature like optimisation or profiling or | whatever. You have a clear mental model of how Cabal is intended to be used -- although it also provides trapdoors (like ghc-options) for when the intended path isn't adequate. But that mental model is much clearer to you and the other Cabal developers than it is to Cabal users like Serge and me. Would it be worth writing a new section in the Cabal manual that describes the intended use model for Cabal, for the benefit of Cabal users? That way you'd be able to explain this stuff once and for all. Documentation often focuses on the knobs (turn the steering wheel to make the car change direction), and omit the larger mental model of what is going on (cars should be driven on a road). Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
On Fri, 2007-10-19 at 11:34 +0400, Serge D. Mechveliani wrote: Currently, my DoCon application has the file docon.cabal, with the field ghc-options: many options ... -O +RTS -M400m -RTS -- -prof -- -auto-all This file defines how to build the DoCon library. And a DoCon user is invited to comment-out or un-comment, or change any of the last 4 lines in this field definition. By this, the user defines, for example, whether to compile the library with -O, with -O2, or with -Onot. The meaning of these options is explained in the GHC documentation. In general the users should never have to modify the .cabal file. For the common settings that we expect the user to want to control Cabal provides configure flags. Ok, so you can get rid of -O and -prof and instead use: runghc Setup.hs configure with our without the following options: --enable/disable-optimization (default is enabled) --enable/disable-library-profiling (default is disabled) Similarly, you do not need to use any language flags, like -fglasgow-exts as you can use the extensions: field. In that field you list the language extensions you need and Cabal knows which compiler options those correspond to (which varies with compiler and compiler version). This also allows you to be more precise about which language extensions you are using. The option -auto-all is not the default for Cabal's --enable-library-profiling but you can make it so using: ghc-prof-options: -auto-all and this option will only be used when the user configures with --enable-library-profiling If it also aimed to build under, say, HBC tool, then, I would probably need to add the field hbc-options: ... and set there the keys according their meaning explained in the HBC documentation. The idea is that instead of having to find the options for each implementation you might want to use, that Cabal knows the right options for each compiler to use a feature like optimisation or profiling or whatever. So the only ones I think you need are: ghc-options: -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports ghc-prof-options: -auto-all extensions: ... Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
On Fri, Oct 19, 2007 at 01:25:27AM +0100, Duncan Coutts wrote: On Thu, 2007-10-18 at 11:02 +0400, Serge D. Mechveliani wrote: On Oct 17, 2007, Don Stewart and Duncan Coutts wrote: [..] By default cabal uses ghc -O to build projects, so you won't see any difference if you comment it out of the cabal file. You will however if you explicitly turn off optimisations: ghc-options: -Onot or: cabal-setup configure --disable-optimization since the default is --enable-optimization which with ghc uses -O For GHC, it is necessary for the .cabal file to provide the field `ghc-options:', and the optimization keys are of this field. Hence, is not this confusing to allow the optimization keys anywhere else? Also seeing `--enable-optimization' the user needs also to recall of what kind of optimization is it. The ghc-options field allows you to pass anything flags you like to ghc. That does not mean that you should! :-) Cabal is supposed to be portable between Haskell implementations and to allow packages to also be portable. Some Haskell implementations provide a notion of optimisation and so Cabal supports that with the --enable-optimization flag. There's an additional advantage here, we can let the user decide if they want to build with or without optimization. With the ghc-options field, only the developer gets to decide. So, in summary it's much better not* to use lines like: ghc-options: -O and to let the user manage that with Cabal's --enable-optimization flag (which is on by default). If you have specific ghc optimisations that you really need to be applied, then it's ok to use the ghc-options: field. For example we use that in bytestring. The --enable-optimization flag also applies to other things, like compiling C code and in principle could apply to other tools like happy/alex, though at the moment it does not. Duncan Currently, my DoCon application has the file docon.cabal, with the field ghc-options: many options ... -O +RTS -M400m -RTS -- -prof -- -auto-all This file defines how to build the DoCon library. And a DoCon user is invited to comment-out or un-comment, or change any of the last 4 lines in this field definition. By this, the user defines, for example, whether to compile the library with -O, with -O2, or with -Onot. The meaning of these options is explained in the GHC documentation. If it also aimed to build under, say, HBC tool, then, I would probably need to add the field hbc-options: ... and set there the keys according their meaning explained in the HBC documentation. This was my idea. I do not know ... Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
On Thu, 2007-10-18 at 11:02 +0400, Serge D. Mechveliani wrote: On Oct 17, 2007, Don Stewart and Duncan Coutts wrote: [..] By default cabal uses ghc -O to build projects, so you won't see any difference if you comment it out of the cabal file. You will however if you explicitly turn off optimisations: ghc-options: -Onot or: cabal-setup configure --disable-optimization since the default is --enable-optimization which with ghc uses -O For GHC, it is necessary for the .cabal file to provide the field `ghc-options:', and the optimization keys are of this field. Hence, is not this confusing to allow the optimization keys anywhere else? Also seeing `--enable-optimization' the user needs also to recall of what kind of optimization is it. The ghc-options field allows you to pass anything flags you like to ghc. That does not mean that you should! :-) Cabal is supposed to be portable between Haskell implementations and to allow packages to also be portable. Some Haskell implementations provide a notion of optimisation and so Cabal supports that with the --enable-optimization flag. There's an additional advantage here, we can let the user decide if they want to build with or without optimization. With the ghc-options field, only the developer gets to decide. So, in summary it's much better not* to use lines like: ghc-options: -O and to let the user manage that with Cabal's --enable-optimization flag (which is on by default). If you have specific ghc optimisations that you really need to be applied, then it's ok to use the ghc-options: field. For example we use that in bytestring. The --enable-optimization flag also applies to other things, like compiling C code and in principle could apply to other tools like happy/alex, though at the moment it does not. Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
mechvel: Dear GHC developers, Has -O any meaning in ghc-6.8.1-candidate ? I build docon under ghc-6.8.1-candidate under -O and with skipping it (the line of -O commented out in docon.cabal). And it installs the .a library of the same size, and the test running takes the same time. By default cabal uses ghc -O to build projects, so you won't see any difference if you comment it out of the cabal file. You will however if you explicitly turn off optimisations: ghc-options: -Onot I'd recommend using -O2 these days, particularly for a library like docon where performance matters. ghc-options: -O2 For best results. -- Don ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
To my question about -O in ghc-6.8.1-candidate Don Stewart wrote on Wed, Oct 17 By default cabal uses ghc -O to build projects, so you won't see any difference if you comment it out of the cabal file. You will however if you explicitly turn off optimisations: I see now, thank you. I'd recommend using -O2 these days, particularly for a library like docon where performance matters. ghc-options: -O2 No, -O2 is worse than -O ! Build the public docon with ghc-6.8.1-candidate under -O and under -O2. Under -O2 1) it is 10% larger and 10% longer to build, 2) demotest/Main runs 10% slower. And the following is close to a bug report: cd demotest ghc $doconCpOpt -O --make Main-- building docon test compiles long and takes 900 Mb of RAM, and after this I kill the process. The same is for ghc $doconCpOpt -O2 --make Main I think, there is not any particular reason to compile the test under -O, usually I apply -Onot here. But still, this very long compilation and 900 Mb are suspicious. Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: -O in 6.8.1-candidate
On Wed, 2007-10-17 at 11:51 -0700, Don Stewart wrote: mechvel: Dear GHC developers, Has -O any meaning in ghc-6.8.1-candidate ? I build docon under ghc-6.8.1-candidate under -O and with skipping it (the line of -O commented out in docon.cabal). And it installs the .a library of the same size, and the test running takes the same time. By default cabal uses ghc -O to build projects, so you won't see any difference if you comment it out of the cabal file. You will however if you explicitly turn off optimisations: ghc-options: -Onot or: cabal-setup configure --disable-optimization since the default is --enable-optimization which with ghc uses -O Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: -O in 6.8.1-candidate
| By default cabal uses ghc -O to build projects, so you won't see any | difference if you comment it out of the cabal file. You will however | if you explicitly turn off optimisations: | | ghc-options: -Onot This is perhaps a bit confusing. Is it documented in the cabal manual? It's not documented under ghc-options in the currently-online manual. Are there any other flags there by default? Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
