August 2022 - cabal-devel

Fwd: Interview request // Mergify
by Artem Pelenitsyn 01 Sep '22

01 Sep '22

Dear cabal devs, I made a "mistake" of opening an issue against Mergify's repo: https://github.com/Mergifyio/mergify/issues/5036 (It had to do with a change in our Mergify config couple month back that didn't work as we expected, but that's beside the point) Couple days after that I got the email I'm forwarding to you. They want an interview with > someone from the Haskell project about your GitHub workflow and how you use Mergify I am not a maintainer, only a casual contributor, so I think it's better be someone more intimately working on cabal development. I CC'ed people who created and updated Cabal's Mergify config, as well as our beloved release manager Mikolaj. Please, let me know if you're interested in talking with them. If not, I guess, I can try to fill these (rather big) shoes, but I'd really rather not. -- Best regards, Artem Pelenitsyn ---------- Forwarded message --------- From: Mergify Support <support(a)mergify.com> Date: Tue, 30 Aug 2022 at 09:06 Subject: Interview request // Mergify To: <a.pelenitsyn(a)gmail.com> Hello Artem, My name is Anne-Laure, and I am a Tech Editor at Mergify. I'm contacting you today because we'd like to interview someone from the Haskell project about your GitHub workflow and how you use Mergify. Examples of already published interviews can be found here: - [They use Mergify series] https://blog.mergify.com/pytorch-lightning-interview/ <https://mergify.intercom-clicks.com/via/e?ob=EUTVvg8QjhoVDcu%2FzfNGYuEjCMJf…> - [This is my workflow series] https://blog.mergify.com/this-is-my-workflow-elastic/ <https://mergify.intercom-clicks.com/via/e?ob=g2JjGZB%2F%2FxJyvpPoOvH5xwDlnb…> Is that something you might be interested in?" Have a great day *Mergify Support* [image: intercom]

2 1

Re: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags?
by Mikolaj Konarski 30 Aug '22

30 Aug '22

> 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. :)

1 0

Re: [Haskell-cafe] With cabal.project, what's the story about warning and -Werror compiler flags?
by Mikolaj Konarski 29 Aug '22

29 Aug '22

Let me CC to cabal-devel(a)haskell.org. On Sun, Aug 28, 2022 at 3:39 PM Nicolas Trangez <ikke(a)nicolast.be> wrote: > > 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.

1 2

Just released: cabal 3.8.1.0
by Mikolaj Konarski 11 Aug '22

11 Aug '22

Here's the happy news. :) Let me copy below the contents of the announcement from https://discourse.haskell.org/t/just-released-cabal-3-8-1-0/4920 but, additionally, on this mailing list I'd like to personally thank Emily and Oleg who, among all the giants on whose shoulders we stand, have most directly affected 3.8.1.0 with their hearts and wisdom. Haskell community owes you big time. --- I’m proud to announce 3.8.1.0 version of Cabal the library and cabal-install the tool. It’s the fruit of concerted effort of innumerous collaborators, from users, through developers, to mentors, caretakers and administrators of our linked community and infrastructure sections. You, people, rock. This version works with the just released GHC 9.4.1 (in fact, for Windows it’s probably necessary) and is already available form GHCup and other channels. More technical details, APIs, changelogs and regressions can be found at Release cabal v3.8.1.0 · haskell/cabal · GitHub. The release is huge, so let me mention only a few random highlights: public/private sublibraries are fully supported and no longer experimental (6. Package Description — Cabal 3.8.1.0 User's Guide) you can now put in your cabal.project something like import: https://www.stackage.org/lts-18.5/cabal.config and it works (7. cabal.project Reference — Cabal 3.8.1.0 User's Guide) new Cabal-syntax and cabal-install-solver packages have been split off there’s no more confusion of compiler options for the local code and for the dependencies (https://github.com/haskell/cabal/pull/7973) one can now define code generators in test stanzas, which is one more principled step away from Custom Setups (https://github.com/haskell/cabal/pull/7688) Cabal badly needs your feedback and your contributions. Please keep them coming.

1 0