On Sun, 2008-11-09 at 14:18 +0100, Petr Rockai wrote:

...

Hi,

"Dmitry Kurochkin" writes:

...

I vote against disabling -Werror. I sometimes miss warnings in build output. And -Werror guarantees that I would not miss it. I think we should disable -Werror only if there is no way around it (or it is too ugly). Conditional compilation for language extensions looks fine to me. for that, I'd say (hope) there'd be better ways to address this than default -Werror. Maybe a cabal flag to turn it on for developers? Or maybe file a wishlist with cabal to have all the warnings appear again at the end of

Hello, On Sunday 09 November 2008 15:10, Duncan Coutts wrote: the

...

compile run? What would you think, Duncan?

People sometimes suggest we should have a feature flag we turn on in devel vs release builds for this kind of thing.

One nice thing about the way cabal files currently work is that they encode the decisions that developers need to make on behalf of users, but that then user choices are not in the .cabal file but expressed as configure flags (eg to build with profiling, optimisation or docs).

Sometimes of course devs need to various combinations of configure flags for their standard development / debugging / testing builds.

One way to do that would not involve encoding all that stuff into the .cabal file would be to have optional build configuration files that the developers use. Basically it'd consist of a set of flags that are passed to cabal configure (though with a more config-file-like syntax).

Indeed it'd be pretty similar to the ~/.cabal/config file but it would apply just to that package.

That would let you add things to the local config file like:

ghc-options: -Werror

and there's no reason why such files could not be put into a darcs repo.

I'm afraid I am not into the complete background here, but I need to ask: What prevents a developer from creating either private (say, shell-) scripts or scripts stored in the repository that executes whatever commands are needed for building, including any special flags needed for that particular build? The possibility of creating such scripts would seem to allow any desired variation of build flags, without any extension to cabal-install. Generally, I am concerned that additional configuration files will increase the work required to debug build problems, such as hunting down the source of any undesired flags that may have been applied.

Though obviously they cannot be included into a distribution tarball (cabal sdist and cabal/hackage check would enforce that).

How would that happen?

Sound reasonable? Should we file a cabal-install feature request?

So far, I lean towards "No" here.

Duncan

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Thanks and best regards Thorkil