With cabal.project, what's the story about warning and -Werror compiler flags?
All, Working on some project, I was wondering about best-practices and community standards for compiler flags now that `cabal.project` is a thing. Before, I put compiler warning flags like `-Wall` in `Ghc-Options` and `Cc-Options` in `mypackage.cabal` files. The use of `-Werror`, whilst (IMHO) useful in development and CI was a bit more troublesome, since having those in `package.cabal` (not under a default-disabled flag) was frowned upon (and even not allowed by Hackage?) 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. Where `-wavx2` could be a required `Cc-Options` setting for a package to build/function, `-Wall` is not. With the advent of `cabal.project`, it seems to me this is the ideal place to put developer flags: from what I understood, `cabal.project` doesn't influence sdist/Hackage distribution, and hence could contain all kind of GHC and C compiler flags that are useful during development but not required for a package to build/function, including `-Werror` (if desired by the project authors). Does this sound like a reasonable stance? 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? Cheers, Nicolas
Let me CC to cabal-devel@haskell.org.
On Sun, Aug 28, 2022 at 3:39 PM Nicolas Trangez
All,
Working on some project, I was wondering about best-practices and community standards for compiler flags now that `cabal.project` is a thing.
Before, I put compiler warning flags like `-Wall` in `Ghc-Options` and `Cc-Options` in `mypackage.cabal` files. The use of `-Werror`, whilst (IMHO) useful in development and CI was a bit more troublesome, since having those in `package.cabal` (not under a default-disabled flag) was frowned upon (and even not allowed by Hackage?)
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. Where `-wavx2` could be a required `Cc-Options` setting for a package to build/function, `-Wall` is not.
With the advent of `cabal.project`, it seems to me this is the ideal place to put developer flags: from what I understood, `cabal.project` doesn't influence sdist/Hackage distribution, and hence could contain all kind of GHC and C compiler flags that are useful during development but not required for a package to build/function, including `-Werror` (if desired by the project authors).
Does this sound like a reasonable stance?
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?
Cheers,
Nicolas _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
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
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
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
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
I was under the impression (but could be mistaken) that Cabal doesn't show warnings while building dependencies.
I don't remember, either, and it depends on commandline options, but I think it does show the full log at least when a dependency fails to compile.
Not that I could find. I should work on a minimal reproducible test- case and file something.
Yes, thank you, please do.
- 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
Brutal but effective. :)
participants (2)
-
Mikolaj Konarski -
Nicolas Trangez