2018-03-01 19:54 GMT+01:00 Ricardo Wurmus <rek...@elephly.net>: > > Gábor Boskovits <boskov...@gmail.com> writes: > > > 2018-03-01 18:11 GMT+01:00 Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> > : > > > >> Hi Guix, > >> > >> we have a problem with jar manifests. When we use the Class-Path > >> property to ensure that an executable can find its dependencies on the > >> class path at run-time, we end up with a manifest like this: > >> > >> --8<---------------cut here---------------start------------->8--- > >> Manifest-Version: 1.0 > >> Class-Path: /gnu/store/i28vi94r8z9f0x02zgkrv87w16ibmqkw-java-htsjdk-2. > >> 10.1/share/java/htsjdk.jar > >> Created-By: 1.8.0_151 (Oracle Corporation) > >> Main-Class: picard.cmdline.PicardCommandLine > >> --8<---------------cut here---------------end--------------->8--- > >> > >> Note that the Class-Path property is broken into two lines. This means > >> that the reference scanner will miss it and grafting will fail. > >> > >> > > Could we modify the reference scanner to find these lines? > > Would there be any serious drawback to that? > > The reference scanner needs to be fast. The scheme version is heavily > optimized to do quickly replace references for the purpose of grafting. > The C++ version will eventually be replaced with the Scheme version as > the daemon gets replaced. > > An alternative to recording full references in the manifest file is to > install a “lib” directory that contains symlinks to dependencies. The > manifest can then contain relative paths to these symlinks. > > I guess I would prefer to do this instead.
> That’s what I did in the package definition for dropseq-tools. > > Unfortunately I cannot find this package. Where should I look for it? > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > >
