-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
upgrade CMakeLists.txt to use external copies of dependencies & no downloading #19
Comments
Hi @mr-c, First of all, thank you for your monumental effort in supporting salmon as a Debian package. I think this is fantastic. I'm also not a CMake expert, but I've failed with it enough times to start to get a handle. I have actually moved to the latest version of Jellyfish (v2.2.3) in the quasimapping branch, which will be merged back into master as soon as we've finished porting the bootstrapping feature from sailfish-master. Regarding supporting external versions of the libraries — this absolutely makes sense. What is the standard location where they are assumed to be installed? In this case I can search with a
For the remaining libraries, we just use the standard versions, so this should be OK. |
Hey @rob-p, you are quite welcome; thanks for the warm response. Being system installed packages most headers and dynamic libraries will be installed using the standard prefixes: /usr/include, /usr/lib/${multiarch-tuple}/, I've updated the checklist above with links to the file lists so you can see the paths yourself. Interestingly I was able to build, run, and pass all the included tests using the version of BWA in the Debian archive. As for Jellyfish I had to update our package to include 'json.h' which had gotten dropped. |
|
Hi guys, Which existing dependencies would you like to be able to use? There are some of these libraries that cannot be replaced by already installed variants. Specifically,
The CMake build system already looks for existing versions of the following before fetching them:
So, the the remaining guys are |
It would be good to get your modifications accepted into BWA & Jellyfish Re: staden-io ships
|
Oh wow; I had no idea about libgff :). Regarding Jellyfish, there's not a source "change" required upstream, rather the fact that I seem to require the Regarding staden, thanks for brining this to my attention. It will probably take a bit for me to wrap my head around the right way to access this information in CMake, but I'll see what I can manage to cobble together on that front (I really wish there was something better, with a less horrendous "language" than CMake, but nothing I know of exists that works nearly as well "out of the box"). |
I don't think http://anonscm.debian.org/cgit/debian-med/salmon.git/plain/debian/patches/jellyfish-update |
Very interesting! It used to be necessary, but perhaps Giullaume fixed this upstream at some point and I just wasn't aware. I'll see if I can merge those changes into Salmon. |
As a user, I prefer autotools to cmake. cmake breaks way more often in my hands/experience than autotools. As a developer, I've only used autotools, so my previous opinion is probably biased. |
staden-io does include an autotools macro :-)
|
I used autotools back in 2008 or so (when I was still working in computer graphics). I found it to be horribly archaic (not that CMake is a bastion of clarity). Also, as opaque as CMake sometimes is, I at least found it easier to discover how to force it to do what I wanted than with autotools. That being said, I feel like it is one of these situations where, if you are a wizard with the tool, everything seems relatively easy and straightforward (e.g. Guillaume uses autotools for Jellyfish, and he seems to have internalized all of the quirks fairly well). I guess I long for a configuration and build DSL that has an actual nice language, rather than the somewhat crazy invocations required by autotools and CMake. Then again, the annals of history are strewn with the wreckage of deprecated and defunct attempts to make better build systems. |
The languages of both autotools and CMake are pretty terrible. I actually like the Make language; I think it gets a bad wrap. Other than |
No, I believe that config.h was it. Otherwise, I just use the already installed headers and the pre-compiled library |
I'll check that Homebrew installs the Jellyfish config.h file. |
I actually think that (as @mr-c points out), the |
Of course, I'm also bumping the version requirement so that we require a Jellyfish version that fixes the "empty read" bug (gmarcais/Jellyfish#55). |
Ah, great. |
The building procedure is still a mess. COMBINE-lab/salmon#19 Package-Manager: Portage-2.3.28, Repoman-2.3.9
And for us, who have blocked download on a computational cluster
|
Document zillions of cryptic dependencies of a lousy package Kingsford-Group/libgff#1 COMBINE-lab/salmon#236 COMBINE-lab/salmon#19 Incomplete install docs are deemed to be at: http://salmon.readthedocs.io/en/latest/building.html#requirements-for-building-from-source Try the command below to see yourself: salmon-0.10.2 $ find . -type f | xargs grep curl 2>/dev/null Thanks to @kiwifb for comments at a1d0487 Package-Manager: Portage-2.3.40, Repoman-2.3.9
Dists downloading their own dependencies is also forbidden in package managers such as FreeBSD ports and pkgsrc (which is cross-platform and I personally use on Mac, NetBSD, and RHEL). Trusting upstream scripts to pull stuff off the Internet is a security risk, so the package managers perform and validate (via checksum) all downloads in a separate stage. It would be nice not to have to hack out the download code from a build system in order to create and maintain a package. |
Hello!
I'm packaging salmon and many of its dependencies for Debian in support of blahah/transrate#160
I have a messy patch to enable the use of external libraries instead of bundled or downloaded copies at http://anonscm.debian.org/cgit/debian-med/salmon.git/plain/debian/patches/dependency-fix
As I'm not a CMake expert I was only able to make it work for Debian instead of a generic solution that would fall back to the shipped copies or downloading as it is now.
Perhaps you all are better with CMake than I am? A generic solution would be best so I don't have to adjust the patch with every change to the CMakeLists.txt
Specifically it would be great to support
I also have a patch to support the latest release of jellyfish that I can turn into a pull request, should you want it: http://anonscm.debian.org/cgit/debian-med/salmon.git/plain/debian/patches/jellyfish-update
Thanks!
The text was updated successfully, but these errors were encountered: