2025/05/02

Newest at the top

2025-05-02 03:49:04 +0200 <geekosaur> 👍
2025-05-02 03:47:47 +0200sajenim(~sajenim@user/sajenim) sajenim
2025-05-02 03:46:45 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-05-02 03:46:12 +0200j1n37-(~j1n37@user/j1n37) (Ping timeout: 252 seconds)
2025-05-02 03:43:34 +0200 <sim590> It might be an easy PR for me to make. I could basically mimic pretty much everything that's done for hsc2hs-options, but do it for c2hs-options.
2025-05-02 03:40:40 +0200 <sim590> But c2hs is not there.
2025-05-02 03:40:33 +0200 <sim590> I don't know if I'm at the right spot, but I see hsc2hs-options seems to be be part of the list of recognized fields here: https://github.com/haskell/cabal/blob/7e0f040d1147770b57e76b2e51123f01e83ce263/Cabal-syntax/src/Di…
2025-05-02 03:40:19 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
2025-05-02 03:37:47 +0200cyphase(~cyphase@user/cyphase) cyphase
2025-05-02 03:35:17 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-05-02 03:34:42 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-02 03:26:28 +0200Typedfern(~Typedfern@135.red-83-37-43.dynamicip.rima-tde.net) typedfern
2025-05-02 03:25:47 +0200 <geekosaur> I told you, it's a development thing. You're trying to use it for something else
2025-05-02 03:25:20 +0200 <sim590> Hmmmm. OK. I don't really know why, but I guess I need prerequisites to undestand it. I don't really know how the build system does its thing, so I don't see the logic here, but OK. So I guess, my only chance now, is to have a fix from the cabal team so that c2hs-options be added to a cabal release.
2025-05-02 03:24:09 +0200Typedfern(~Typedfern@135.red-83-37-43.dynamicip.rima-tde.net) (Remote host closed the connection)
2025-05-02 03:23:44 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2025-05-02 03:21:28 +0200typedfern_(~Typedfern@135.red-83-37-43.dynamicip.rima-tde.net) (Ping timeout: 276 seconds)
2025-05-02 03:18:56 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-02 03:18:26 +0200Typedfern(~Typedfern@135.red-83-37-43.dynamicip.rima-tde.net)
2025-05-02 03:17:30 +0200 <geekosaur> but you need to include a `packages:` entry, which would override the main one and result it the package being installed in its own project's `dist-newstyle` where it won't be found by the main project
2025-05-02 03:16:12 +0200 <sim590> So for your question, I guess it both files could be nested. The user's file and the dependency's file?
2025-05-02 03:15:47 +0200 <geekosaur> (unfortunately most of the dev team is asleep at this time of their night)
2025-05-02 03:15:39 +0200 <sim590> OK, thanks for the initiative.
2025-05-02 03:15:09 +0200 <geekosaur> fwiw I just asked about `c2hs-options` not working in the cabal dev channel; it seems very wrong that it works in a project file but not the cabal file
2025-05-02 03:14:27 +0200 <geekosaur> someone's using your package as a dependency in a development tree with a `cabal.project`. what happens?
2025-05-02 03:13:53 +0200 <sim590> I don't understand the question.
2025-05-02 03:13:33 +0200 <geekosaur> what's supposed to happen if it's already using `cabal.project`?
2025-05-02 03:13:12 +0200 <geekosaur> 100% sure
2025-05-02 03:12:02 +0200xff0x(~xff0x@2409:251:9040:2c00:1c47:7f78:37e8:e2a1) (Ping timeout: 265 seconds)
2025-05-02 03:11:55 +0200 <sim590> hmmmm. I tried many things with the cabal file but it didn't work. :/ Are you 100% sure cabal.project won't be used when compiling as transitive dependency? If the file is there, why would it work differently when it's build as a transitive dependency?
2025-05-02 03:09:32 +0200cyphase(~cyphase@user/cyphase) (Ping timeout: 252 seconds)
2025-05-02 03:08:04 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-05-02 03:06:18 +0200fantom(~fantom@2.219.56.221) (Ping timeout: 244 seconds)
2025-05-02 03:05:58 +0200a_fantom(~fantom@33be818f.skybroadband.com)
2025-05-02 03:04:37 +0200 <geekosaur> then you need to find a way to get that into the cabal file, because a project file, even if you manage to include one, won't be used when building as a transitive dependency
2025-05-02 03:04:06 +0200 <sim590> I need to have `c2hs-options: -C -std=gnu18` shipped with my package.
2025-05-02 03:03:10 +0200 <sim590> But, my package needs to build on other people's computer. And for that it needs the fix for GCC 15.
2025-05-02 03:03:08 +0200 <geekosaur> projects are a development thing, not a deployment thing
2025-05-02 03:03:08 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-02 03:02:43 +0200 <geekosaur> cabal.project isn't normally uploaded at all, since hackage doesn't understand projects, only packages
2025-05-02 03:02:03 +0200 <geekosaur> /home/allbery/.config/hexchat/logs/irccloud bnc/#hackage.log-Apr 09 03:12:12 <sclv> probably a brief delay, no more than five minutes
2025-05-02 03:00:23 +0200 <sim590> extra-source-files?
2025-05-02 02:59:43 +0200 <sim590> So, I just made a package release with `cabal sdist`, but it didn't include the `cabal.project` file. Which ignores my previous fix. What cabal field should I use to include that file?
2025-05-02 02:59:25 +0200 <geekosaur> I thought I had a discussion in my backscroll but I'm not finding it now
2025-05-02 02:59:11 +0200 <geekosaur> all I can say is that it takes several minutes
2025-05-02 02:57:29 +0200 <sim590> nvm. it was pretty quick. I guess it might have been my version rule that wasn't right.
2025-05-02 02:56:33 +0200ttybitnik(~ttybitnik@user/wolper) (Quit: Fading out...)
2025-05-02 02:55:38 +0200__jmcantrell__(~weechat@user/jmcantrell) jmcantrell
2025-05-02 02:53:36 +0200 <sim590> How much time after you pushed a new package version to hackage does it take usually for cabal update to pick the new version?
2025-05-02 02:52:52 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)