From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecrGj-0001FW-Uq for guix-patches@gnu.org; Sat, 20 Jan 2018 06:25:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecrGf-0005vc-Rf for guix-patches@gnu.org; Sat, 20 Jan 2018 06:25:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:55935) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ecrGf-0005vR-P6 for guix-patches@gnu.org; Sat, 20 Jan 2018 06:25:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ecrGf-0006MU-K4 for guix-patches@gnu.org; Sat, 20 Jan 2018 06:25:01 -0500 Subject: [bug#29896] [PATCH] gnu: java-asm: Update to 6.0. Resent-Message-ID: Date: Sat, 20 Jan 2018 12:24:24 +0100 From: Julien Lepiller Message-ID: <20180120122424.1016d079@lepiller.eu> In-Reply-To: References: <20171229190022.22705-1-boskovits@gmail.com> <20180107212356.18556-1-boskovits@gmail.com> <87efmmtky1.fsf@gmail.com> <20180120001202.GC18016@jasmine.lan> <87fu71ufxo.fsf@gmail.com> MIME-Version: 1.0 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: 29896@debbugs.gnu.org Le Sat, 20 Jan 2018 10:08:04 +0100, G=C3=A1bor Boskovits a =C3=A9crit : > 2018-01-20 8:50 GMT+01:00 Chris Marusich : >=20 > > Leo Famulari writes: > > =20 > > > On Thu, Jan 18, 2018 at 10:35:34PM -0800, Chris Marusich wrote: =20 > > >> Even though we added some inputs, there appear to be no retained > > >> references in the output, as shown by this command: > > >> > > >> guix gc --referrers $(./pre-inst-env guix build java-asm) =20 > > > > > > To check the retained references in the output [0], it's actually > > > `guix gc --references $(./pre-inst-env guix build ...)`. > > > > > > [0] To clarify "retained references", they are literally > > > occurences of strings that begin with '/gnu/store/', then a Guix > > > hash, then a hyphen, and then a package name. =20 > > > > You're right; this was a "thinko" on my part. I meant to write > > "--references" instead of "--referrers". The output of the correct > > command is still empty, so there are still no references. > > > > Ricardo Wurmus writes: > > =20 > > > Chris Marusich writes: > > > =20 > > >> If the new input is also required at runtime, then I'm not sure > > >> this package definition is correct. I would normally expect a > > >> "runtime dependency" to be either retained as a reference in the > > >> output, or declared as a propagated-input (so that it gets > > >> installed alongside this package when this package is installed > > >> into a profile). Perhaps I am missing some information here. > > >> > > >> I'm hoping Ricardo can comment on how this is intended to work > > >> for Java packages, since he originally added the > > >> ant-build-system. =20 > > > > > > The jars that the ant-build-system generates are uncompressed and > > > thus allow the scanner to find embedded store references. The > > > problem seems to be that references to other *jars* are not kept, > > > because they are never recorded anywhere. That=E2=80=99s normal for > > > Java, which looks for named classes on the classpath, i.e. a list > > > of jars. It behaves very much like Python and its PYTHONPATH in > > > this regard. > > > > > > The best we can do here is to propagate inputs. The alternative > > > is to try to be smart and record the effective runtime classpath, > > > but that=E2=80=99s hard/impossible to get right. =20 > > > > OK - thank you for the explanation! In light of that information, I > > think that in the case of a package that uses the ant-build-system > > (like java-asm), if we know for sure that an input is required at > > runtime, we should make it a propagated input. The installed > > software still won't work without additional work on the part of > > the user (e.g., the user needs to set the CLASSPATH when invoking > > java, or use java's -cp option), but for now at least making the > > input a propagated input will ensure that it gets installed > > alongside the package which at runtime requires it, which is better > > than nothing. > > > > Here's an updated patch that makes this change. In addition, I > > discovered that (1) the build succeeds and produces the same JAR > > file even when I removed java-aqute-libg as an input, so I've > > removed that, and (2) the build succeeds and produces the same JAR > > file even when I use a dummy value for the biz.aQute.bnd.path Ant > > property, so I did that to make it clear that it wasn't important > > to the build. What do you think? > > > > I think this is ok. I also noticed, that a dummy value would do, > > but I had =20 > no policy > at hand about what to do in this case. >=20 > Actually I am not sure, that bnd is used runtime. How could we check > that? Try to run it when bnd is not in the CLASSPATH? There's a method to get references to a dependency in java: you can put it in the MANIFEST.MF file as: Class-Path: /gnu/store/... It's a space-separated list of jar files that have to be added to the classpath. This could be done in a phase that runs just before the build phase, like the phase that adds a Main-Class. >=20 >=20 > > -- > > Chris > > =20