outpaddling
commented
2 years ago Looks like some progress has been made leading up to 1.6.0. The only thing cmake insists on embedding in the build now is pufferfish. Seems like it should be relatively easy to tweak cmake to use a separate install of this since it's already a separate Github project.
However, it appears to use a COMBINE-lab fork of staden-io, which makes it impractical to install that as a separate package, since it would conflict with the mainstream version. The Debian package for staden-io_lib is from https://github.com/jkbonfield/io_lib.
I did get a successful build under FreeBSD ports: https://github.com/outpaddling/freebsd-ports-wip/tree/master/salmon.
Good morning,
I'm a *nix developer with a lot of experience porting software to various platforms. My preferred method for deployment is build-from-source package managers such as FreeBSD ports, Gentoo Portage, MacPorts, pkgsrc (which I use extensively on CentOS), etc. Package managers in-general minimize problems for end users (and hence reduce PRs for you guys). Build-from-source package managers also allow customizing build options (e.g. adding -march=native), which can sometimes offer significantly better performance than you can get from a generic binary package that has to support older CPUs.
Currently, developing such packages for salmon is a challenge due to the way the build system works. I've been looking through the build system and the main barrier to packaging is the unconditional bundling of some dependencies, such as seqlib and htslib. If you were to update the cmake systems so that they first look for all dependencies installed externally, as they already do for jemalloc and tbb, then it would be easier for developers to package salmon.
Best,
Jason