[Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags?

[Nicolas Trangez]

Hey Mikolaj,

On Mon, 2022-08-29 at 06:58 +0200, Mikolaj Konarski wrote:
> Hi Nicolas,
> 
> > Before, I put compiler warning flags like `-Wall` in `Ghc-Options`
> > ..
> > Having these options in `mypackage.cabal` always felt slightly
> > weird,
> > since they are in no way required for a package to function:
> > they're
> > developer options, not user/consumer options.
> 
> They'd be certainly out of place in a binary package. However,
> a source package is meant to be compiled, so instructing
> the compiler to produce warnings during compilation seems relevant.

I was under the impression (but could be mistaken) that Cabal doesn't
show warnings while building dependencies. Even if it would, and some
warning passes by, what's a user (of some package depending on mine)
supposed to do when such warning(s) pass by, as long as it doesn't make
compilation fail?

> A related reason is that IIRC haskell-ci does `cabal sdist` and then
> runs all its operations based on the resulting source package.

Indeed it does. Hence, I configured HaskellCI to copy the warnings (and
-Werror) from the project's cabal.project into the one it generates,
for exactly this reason.

As long as only warnings are used in ghc-options of cabal.project,
there shouldn't be a difference between build'ability of the sdist, but
we could make things fail in CI if warnings pop up (for the
supported/tested GHC versions only, of course).

> So, if you want to see warnings in CI logs, you need to retain
> the relevant instruction in the source package created by `cabal
> sdist`.

I don't think it's OK to rely on "people looking at CI logs". If CI
passes, then things are in good shape, no matter what's in the CI logs.
Hence, the only way to ensure no code introducing warnings gets
introduced, is by having -Werror in CI.

> And warnings sometimes help to explain why compilation fails
> or why the resulting binary misbehaves.

Fair point, in some cases.
> 
> > > If it is, I did run into a couple of issues getting things to
> > > actually
> > > work. Whilst putting `Ghc-Options` in a `Package mypackage`
> > > section in
> > > `cabal.project` seems to work, I'm unable to achieve the same
> > > resulsts
> > > for C compiler invocations. Presumably there's a `Gcc-Options`
> > > setting
> > > one can use (which is also generated in `cabal.project.local` by
> > > `cabal
> > > configure --gcc-options ...`). However, in testing, it appears
> > > said
> > > compiler optons are only passed to GCC when compiling, e.g., a
> > > HSC2HS
> > > file, but not when compiling a C file part of a `C-Sources`
> > > setting
> > > (whilst `Cc-Options` in `mypackage.cabal` are).
> > > 
> > > Is there some discrepancy between what can be done from
> > > `cabal.project`
> > > vs. `mypackage.cabal`? Is this intentional? Am I trying to
> > > accomplish
> > > something that isn't/shouldn't be supported by Cabal in the first
> > > place?
> 
> That sounds like a bug. Is there anything relevant in the issue
> tracker?

Not that I could find. I should work on a minimal reproducible test-
case and file something.

Meanwhile, I guess from the feedback, what'd be best is to

- Keep warnings in package.cabal ghc-options/cc-options etc
- Add -Werror in cabal.project so things fail on dev machines
- Configure HaskellCI to have -Werror as well, given a no-warnings
policy

Nicolas