Dear reviewers, Can I make the review process easier by posting the patches in separate threads?
Thanks! Kind regards, Roel Janssen Ricardo Wurmus writes: > Roel Janssen <r...@gnu.org> writes: > >> Dear Guix, >> >> In an effort to package freebayes, I would first like to add vcflib and >> its dependencies. Therefore, I have attached eight patches. >> >> I've attempted to decouple the dependencies from vcflib, which worked >> for intervaltree and htslib. The following dependencies are actually >> tightly coupled in the build process: >> - tabixpp >> - smithwaterman >> - multichoose >> - fsom >> - filevercmp >> - fastahack > > Thank you for your efforts! > >> To decouple these, we would need to include header files in the package >> output that aren't part of the public interface. In addition to that, >> we would need to patch the build system to not look for <object>.o, but >> instead add the right directives to the linker. > > I see what you mean. This is ugly, but there isn’t much you can do > about this. I’ve encountered many packages that do the same (some of > which also involve tabix), and in the case of “libvcflib.a” it really > does seem very hard to untangle dependencies further. > > “filevercmp” and “fsom” don’t install libraries at all and apparently > are supposed to be included in other code. > >> I don't think that is the desirable approach, because that would cause >> these packages to provide header files that should only be used >> internally. Therefore, I use the source of these packages in vcflib, >> and unpack them in the vcflib project root, to avoid confusion on >> interfaces and fiddling with the build system. > > This seems acceptable to me. I haven’t yet looked at your patches, but > the justification you give is valid; I looked at the Makefiles of vcflib > and included projects and I think this is okay. > > ~~ Ricardo