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

[Mikolaj Konarski]

Another angle is that cabal.project is for a set of packages
and foo.cabal is for an individual package foo.
That distinction would suggest cabal.project is only for compiler
options that affect all packages in the project.
However, with 1-package projects, this is a moot point.

OTOH, given that Hackage does not accept package collections,
but only individual packages, and this is how packages
are compiled as dependencies, all packages (or at least all
libraries) need to be ready to behave like 1-package projects
even bereft of cabal.project files. (BTW, I wonder, perhaps Hackage
should accept package collection for non-libraries, that is,
for packages that are not intended solely to be dependencies
of other packages.) Perhaps putting in cabal.project only what
is not needed for the use as a dependency of another package
makes sense. E.g., only the options affecting executable
components of the packages.

On Mon, Aug 29, 2022 at 6:58 AM Mikolaj Konarski <mikolaj at well-typed.com> 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.
> A related reason is that IIRC haskell-ci does `cabal sdist` and then
> runs all its operations based on the resulting source package.
> 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`.
> And warnings sometimes help to explain why compilation fails
> or why the resulting binary misbehaves.
>
> > > 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?
>
> All the best,
> Mikolaj