Hi Andreas, >> However, the build still fails with: >> >> In file included from >> /build/salmon-0.7.1+ds1/include/UtilityFunctions.hpp:5:0, >> from /build/salmon-0.7.1+ds1/include/SBModel.hpp:7, >> from /build/salmon-0.7.1+ds1/src/SBModel.cpp:1: >> /build/salmon-0.7.1+ds1/include/SalmonUtils.hpp:32:27: fatal error: >> RapMapUtils.hpp: No such file or directory >> >> which suggests that salmon also uses parts of the previous embedded or >> downloaded RapMap source tree to build salmon, not just the binary. >> I’m not familiar enough with RapMap’s intended use to decide whether we >> should introduce a rapmap-dev package given that it doesn’t seem to build a >> library. Any hints? > > Possible quick-n-dirty, solution: Just add a code copy of > RapMapUtils.hpp either as quilt patch or in debian/rapmap and copy over > in build process.
Sure, that’s always an option. > This might help us whether the new version would > really fix the original build issue of #835720. Looking at the error message, the original build issue looks like something I had to fix in RapMap as well, as there was a mismatch between the version of spdlog whose API salmon and RapMap were using and the one packaged in Debian. So I guess this will be fixed if we include Debian’s patched copy of the required RapMap code or — if not -- I know how to fix it. > Proper solution is probably to contact upstream (I think its the same > for rapmap and salmon) how to sensibly solve this issue. I’d rather get it to work for now and will try including the smallest necessary set of code needed to build salmon. It is definitely more than one file; currently I’m using trial and error to arrive at a minimal set. I have also opened https://github.com/COMBINE-lab/salmon/issues/87, let’s see what they say. Cheers Sascha
signature.asc
Description: Message signed with OpenPGP using GPGMail
