
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 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. Though obviously they cannot be included into a distribution tarball (cabal sdist and cabal/hackage check would enforce that). Sound reasonable? Should we file a cabal-install feature request? Duncan