2018-01-20 8:50 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:

> Leo Famulari <leo@famulari.name> writes:
>
> > On Thu, Jan 18, 2018 at 10:35:34PM -0800, Chris Marusich wrote:
> >> 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)
> >
> > 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.
>
> 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 <rekado@elephly.net> writes:
>
> > Chris Marusich <cmmarusich@gmail.com> writes:
> >
> >> 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.
> >
> > 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’s 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’s
> > hard/impossible to get right.
>
> 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
no policy
at hand about what to do in this case.

Actually I am not sure, that bnd is used runtime. How could we check that?


> --
> Chris
>