On Thu, 2008-01-17 at 07:27 -0800, Adam Langley wrote:

On Jan 17, 2008 5:51 AM, Adrian Hey wrote:

...

IOW, if I already have.. ghc-options: -O2

As an aside, I believe that -O2 in ghc-options is considered poor form because cabal handles the -O options itself (so that --disable-optimization and friends work).

Yes.

There's a trac ticket to write a patch to warn about this, which I did at some point but, come to think of it, never heard about it again. Oh well,

Did you? Oh, that'd be great. Where is the patch? Duncan

On Thu, 2008-01-17 at 15:31 -0800, Adam Langley wrote:

On Jan 17, 2008 2:35 PM, Duncan Coutts wrote:

...

Did you? Oh, that'd be great. Where is the patch?

I had an hour to kill. I think I remember being a little unsure about where the code for the 3rd one should hook in.

Yeah, that's not immediately obvious. It depends on when we want to give those warnings. Eg it's ok to have some of those flags locally but we want to warn if you're preparing a package to distribute. So I'm leaning towards putting the check in sdist and perhaps also in it's own qa/check/lint command. Oh and of course to export it and use it in hackagedb's upload code too.

Mon Dec 31 09:47:09 PST 2007 agl@imperialviolet.org * Ticket 176: Fix verbosity error to include the valid -v values

We'd got a patch for this on in the mean time, though I prefer your clearer error message so have applied it and resolved the conflict.

Mon Dec 31 10:05:16 PST 2007 agl@imperialviolet.org * Ticket 201: report IO errors during clean

Applied.

Mon Dec 31 10:40:21 PST 2007 agl@imperialviolet.org * Ticket 191: check for common, unwise GHC options

Sorry, duplication here. Lennart sent in a patch for this yesterday and I think I prefer that approach. Though there's still work to do in linking the checks into the right places as I describe above. So thanks very much for the patches. Next time send them in as soon as you write them :-) and we'll avoid duplicated work. (I might be going mad, but I don't think I saw them sent to any list.) Next time you have a spare hour for Cabal, I'd suggest looking at the one on striping: http://hackage.haskell.org/trac/hackage/ticket/88 Several packages are now using ghc-options: -opl-Wl,-s which is not great because I don't think that works on all platforms and it causes problems for distros that prefer to handle striping themselves. Duncan

Duncan Coutts wrote:

On Thu, 2008-01-17 at 13:51 +0000, Adrian Hey wrote:

...

Hello,

Looking at the latest Cabal docs, I see that in addition to ghc-options, there are also ghc-prof-options and ghc-shared-options. What isn't clear to me though from the docs is that are the latter two in addition to the first, or are they a substitute for the first (for profiling/shared).

IOW, if I already have.. ghc-options: -O2

will the O2 also be applied to profiling build (say)? Or do I need an extra explicit.. ghc-prof-options: -O2

They are additive.

I'm not at all convinced about these fields. It's not clear what their use cases are.

As Adam says, adding -O is discouraged. If I had my way I'd make hackage require a performance profile to be supplied along with any package that wanted to use -O2 over -O.

Thanks. Personally I'm not at all sure that having users specify all this stuff on the command line is a good idea. I thought policy was that (ideally) all users should have to do is type.. runghc Setup configure runghc Setup build ..etc If users don't like the defaults defined in the .cabal file they can always edit it (that way they have a record of what was actually used to build the package). I habitually add -split-objs to the ghc-options of stuff I download, for example. I have read about --enable-split-objs, I just don't like using it. I do use --enable-library-profiling habitually, but only because I haven't figured out how to put this in the .cabal file :-) Regards -- Adrian Hey