From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:51605) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2EvP-0006sf-J3 for guix-patches@gnu.org; Thu, 13 Feb 2020 08:53:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2EvO-00035A-Gs for guix-patches@gnu.org; Thu, 13 Feb 2020 08:53:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:53465) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j2EvN-00034i-UC for guix-patches@gnu.org; Thu, 13 Feb 2020 08:53:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j2EvN-0005fO-SQ for guix-patches@gnu.org; Thu, 13 Feb 2020 08:53:01 -0500 Subject: [bug#39309] [PATCH WIP] gnu: add stack. Resent-Message-ID: MIME-Version: 1.0 References: <87k14vou0u.fsf@ngyro.com> In-Reply-To: <87k14vou0u.fsf@ngyro.com> From: John Soo Date: Thu, 13 Feb 2020 13:52:22 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Timothy Sample Cc: 39309@debbugs.gnu.org Hi Tim, > This seems to be due to . > > Briefly, the =E2=80=9Chsc2hs=E2=80=9D program bundled with GHC 8.6.5 acce= pts response > files, but then goes ahead and passes arguments directly to GCC. Newer > versions of =E2=80=9Chsc2hs=E2=80=9D use response files for GCC, which so= lves the > =E2=80=9CArgument list too long=E2=80=9D problem. > > My first suggestion would be to make a separate package for =E2=80=9Chsc2= hs=E2=80=9D > using the version listed on Stackage (which is 0.68.6). Then, add it as > a native input to the =E2=80=9Cstack=E2=80=9D package and get it to shado= w the version > shipped with GHC. I added hsc2hs@0.68.6 as a native input to stack but I'm not sure how to make it shadow the ghc package. Used as a native input hsc2hs does not fix the issue. I suppose another option would be to use the #:haskell key to use a locally-patched version. I am not familiar with ghc internals aside from having built from source a few times so I can look into that option. > Failing that, we could consider patching our GHC package. It would be > best to avoid that, though! :) Agree! I think we should try shadowing hsc2hs first. I might even suggest bumping lts/ghc versions before we patch our version. > (Also, there=E2=80=99s a duplicate =E2=80=9Cghc-hspec-discover=E2=80=9D i= n the patch set. That > is, we already have an =E2=80=9Chspec-discover=E2=80=9D package.) Oops! Sorry! It's definitely the importer. I know I'm not the first to have the problem. Maybe we should open an issue to fix that? Thanks! John