bamtools installation conflicts with HLA-LA makefile settings

[boyangzhao]

The makefile settings doesn't seem to be fully compatible with bamtools (version tested 2.5.1). I installed my bamtools not in the build directory but in a different directory (defined in DCMAKE_INSTALL_PREFIX). If the a user installs it this way (see example below), then where is no src in the installed location and also it seems with version 2.5.1, the lib location is not named lib64 as suggested in the HLA-LA makefile. Note I'm aware there is also the commented out codes in makefile for the older bamtools version as well, but still either way it's not fully compatible, and needs tweaking...

Methods used for bamtools installation, which doesn't quite work with the makefile defined by HLA-LA

git clone --branch v2.5.1 git://github.com/pezmaster31/bamtools.git
cd bamtools
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$BAMTOOLS_PATH ..
make
make install

[brettva]

@boyangzhao I was on this for quite a while but ended up actually getting this about 20 minutes after I pinged you. At least this is what worked for me. I am not a developer for this group, just a user. But this setup seems to result in a installation that checks out with their test data set

I used bcftools v2.5.1. The expected lib64 is lib like you mentioned, which threw me off.

I didn't use any of the commented out code in the makefile, even though it looks like that might be the right code to use given the lib location suffix.

I changed line 11 from BAMTOOLS_LIB = $(BAMTOOLS_PATH)/lib64

I did not mess around with include statements in mapper/processBAM.cpp, like line 17 mentions

This stuff might be unique to my setup, but like the documentation mentions, I actually did have to hard link all of the boost libraries in line 14 in addition to the libz location, eg:

LIBS = -L$(BOOST_LIB) -L$(BAMTOOLS_LIB) /path/to/boost/lib/libboost_random.a /path/to/boost/lib/libboost_filesystem.a /path/to/boost/lib/libboost_system.a -lbamtools /usr/lib/x86_64-linux-gnu/libz.a /path/to/boost/lib/libboost_serialization.a

[boyangzhao]

Nice. Instead of renaming BAMTOOLS_LIB, I ended up changing the actual folder name itself: from ${BAMTOOLS_PATH}/lib to ${BAMTOOLS_PATH}/lib64, so it matches the one described in makefile. Below were the steps I did to make the installation work,

cd /tmp
git clone --branch v2.5.1 git://github.com/pezmaster31/bamtools.git
cd bamtools 
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$BAMTOOLS_PATH ..
make
make install
cp -r /tmp/bamtools/build/src ${BAMTOOLS_PATH}/src
mv ${BAMTOOLS_PATH}/lib ${BAMTOOLS_PATH}/lib64

Note I've defined an environment variable for BAMTOOLS_PATH to point to the location I want to install bamtools.

I'm keeping issue open here since it would be great if this is in the documentation or update the way installation works so this is not an issue.

@brettva did you get any runs to work though? After things installed, were you able to run the example cram file? I get error messages at run time, and if I run my bam files, I get a segmentation fault (raised in a separate issue here).

[brettva]

@boyangzhao thats what I meant by checks out with their test data set. I got it to work with the cram file and output is as expected in their demo output file. I had to run this twice:

../bin/HLA-LA --action prepareGraph --PRG_graph_dir ../graphs/PRG_MHC_GRCh38_withIMGT

I got an error BWTIncConstructFromPacked() : Unexpected end of file first time I ran the cram file. Wishful thinking I regenerated the graph ran it again and it worked (sometimes our cluster gets hammered and things fail just because of I/O issues), sorry not exactly a reproducible fix.

I run mummer-3.9.4 bwa 0.7.17-r1188 samtools 1.9-63-g649f04f minipamp2 v2.17 picard-tools 1.119 + 1.83, the exact same they have in the paths.ini file.

Maybe its not a big deal, but they should probably have version numbers for the mummer bins, picard tools, and minimap in the documentation.

I am about to try with my own bam, I'll comment in that thread if I get similar issues.

[boyangzhao]

Thanks @brettva , I ended up changing line 11 of makefile like you did, and a few other changes to, including now using samtools 1.9 - didn't trace through to which one mattered, but I can also now run the .cram example file. But I noticed there are more lines in my R1_bestguess_G.txt than the example. My run also includes loci DPA1/DPB1/SRB3/DRB4/E/F/G. The A/B/C/DQA1/DQB2 are the same as those in example. Did you get the same result like this?

My bam still fails - not sure why yet.

[brettva]

@boyangzhao Me too, I just made sure the ones that they describe in the example were exactly what I go with the cram file. Maybe the developers can let us know how to properly compare the other ones. Thats cool that those changes seemed to work. Normally I would find a way to share my bam with you for sanity checks but I work with PHI and can't

[boyangzhao]

No worries, thanks!

[AlexanderDilthey]

The current version of HLA*LA can successfully be compiled with the current version of bamtools. Closing this now.