From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: gradle not supported? Date: Wed, 24 Jul 2019 23:55:28 +0200 Message-ID: <87lfwn9jxr.fsf@elephly.net> References: <20190724152859.741c8ad4@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:46592) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqPEV-00021S-Cg for guix-devel@gnu.org; Wed, 24 Jul 2019 17:55:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hqPEU-0005me-Cu for guix-devel@gnu.org; Wed, 24 Jul 2019 17:55:35 -0400 Received: from sender4-of-o53.zoho.com ([136.143.188.53]:21348) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hqPEU-0005ln-2m for guix-devel@gnu.org; Wed, 24 Jul 2019 17:55:34 -0400 In-reply-to: <20190724152859.741c8ad4@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Jesse Gibbons Cc: guix-devel@gnu.org Hi Jesse, > I noticed when I search the code for gradle I get > - code deleting the provided gradle jar > - comments about keeping a version of two different packages back > because they require gradle.=20 > > I'm guessing the gradle jar is deleted because it isn't compiled for > guix. But why are these packages (java-htsjdk and java-picard in > gnu/packages/bioinformatics.scm) held back to not depend on gradle? That=E2=80=99s because we can=E2=80=99t build packages that depend on gradl= e without depending on an opaque binary that we cannot (yet) build. > If I need a package that uses gradlew to build, what is the best > solution for defining it? IIUC gradle usually downloads a version of gradle as the first step. Building a package that uses gradlew may currently require a lot of manual work to essentially avoid the use of gradle as we have no gradle build system yet. A more constructive way would be to figure out a way to provide a gradle-build-system that works around the problems we have with gradle in one way or another, so that this is fixed for all future packages depending on gradle. Tricky. --=20 Ricardo