CMake compilation of own projects which use BamTools

74 views
Skip to first unread message

Karel Břinda

unread,
Oct 8, 2014, 10:19:34 AM10/8/14
to bamtoo...@googlegroups.com
Hello everybody,

I like BamTools, it is a nice and useful project. I use it in some of my programs.

It is nice that BamTools are compiled using CMake. However, I don't understand why it is forbidden for users to build it in the main project directory. This barrier is very annoying for me since I have to delete the lines responsible for it in the main CMakeLists.txt file:

# Force the build directory to be different from source directory
macro( ENSURE_OUT_OF_SOURCE_BUILD MSG )
    string( COMPARE EQUAL "${CMAKE_SOURCE_DIR}" "${CMAKE_BINARY_DIR}" insource )
    get_filename_component( PARENTDIR ${CMAKE_SOURCE_DIR} PATH )
    string( COMPARE EQUAL "${CMAKE_SOURCE_DIR}" "${PARENTDIR}" insourcesubdir )
    IF( insource OR insourcesubdir )
        message( FATAL_ERROR "${MSG}" )
    ENDIF( insource OR insourcesubdir )
endmacro( ENSURE_OUT_OF_SOURCE_BUILD )

ensure_out_of_source_build( "
  ${PROJECT_NAME} requires an out of source build.
  $ mkdir build 
  $ cd build
  $ cmake ..
  $ make 
(or the Windows equivalent)\n" )



Maybe there are more possibilities how to add it to own CMake project, I do it using these lines:

add_subdirectory( bamtools )
include_directories ( bamtools/src )
target_link_libraries(my_project BamTools)


Nevertheless, whenever I run
I have to remove manually those lines blocking this type of compilation.


I have 2 ideas about what could help many BamTools users:
  • Remove these blocking lines.
  • Add a simple tutorial about adding BamTools to own CMake projects (e.g., using my 3 lines).

Best regards

Karel

Derek Barnett

unread,
Oct 8, 2014, 10:49:10 AM10/8/14
to bamtoo...@googlegroups.com
Hi Karel,
Thanks for the feedback.

The short answer is to this is that I am simply not touching the build system until the next major release (v3.0), so as not to break any existing build automation w/o proper warning. v3.0 will involve some API source changes as well, so that seems a good opportunity to let client developers do a once-over revamp of their BT use.  

I apologize for current inconveniences, but I've learned a lot since I initially set this project up and promise that v3.0 will be a much cleaner beast to work with. 

Thanks again,
  - Derek

--
You received this message because you are subscribed to the Google Groups "bamtools-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bamtools-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

André Blavier

unread,
Oct 8, 2014, 10:54:22 AM10/8/14
to bamtoo...@googlegroups.com
Hi Derek,
Sorry to interrupt this discussion but I am intrigued with the next
major release (v3.0). Can I ask which new features will be included?
Thanks,

Andre

> * Remove these blocking lines.
> * Add a simple tutorial about adding BamTools to own CMake


> projects (e.g., using my 3 lines).
>
>
> Best regards
>
> Karel
>
> --
> You received this message because you are subscribed to the Google
> Groups "bamtools-user" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to bamtools-use...@googlegroups.com

> <mailto:bamtools-use...@googlegroups.com>.


> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "bamtools-user" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bamtools-use...@googlegroups.com

> <mailto:bamtools-use...@googlegroups.com>.

Derek Barnett

unread,
Oct 8, 2014, 12:21:46 PM10/8/14
to bamtoo...@googlegroups.com
Andre and all interested,

The primary motivations for v3.0 include:

1 ) exactly what we're discussing here - cleaning the build system: 

   1.1) probably removing the absolute requirement for out-of-source builds (though encouraging it via docs)
   1.2) cleaner #include paths (e.g. " #include <bamtools/BamReader.h> " )
   1.3) better support for 'make install', whether in standard or custom locations

2) dropping the utils library, to avoid unnecessary complication and confusion on the part of many developers. Anything in that library will be migrated either to the toolkit source or as a first-class, documented citizen of the API.

3 ) overhauling the BamAlignment structure. 

    The idea there being to extend the lazy-loading of alignment fields beyond the current "core only" or "everything parsed" states. Basically any single field that needs to be interpreted from the raw data (CIGAR, bases, qualities, tags, etc) will only be parsed out on-demand. This has a few immediate benefits: 
  
  2.1) it simplifies the API - no longer any need for 2 different BamReader::GetNextAlignment methods. Just get the next alignment and query whatever you need. 
  
  2.2) it will speed up 'core only' style fetching. Currently the CIGAR is interpreted for GetNextAlignmentCore(). GNACore is handy in a lot of indexing/sorting operations that don't need the other string fields, but do need to know the CIGAR and/or end position. On the other hand, in the most general case, as we're iterating through a region of interest - we don't need to know the CIGAR up front (we know the alignment position falls within our range). So we save that parsing step. This can be quite significant in some data types (e.g. PacBio alignments) that have rather complex CIGAR strings.

  2.3) Some of the BamAlignment fields may be renamed to reflect updated SAM/BAM spec terminology. 

  2.4) I'm also tinkering with a built-in "tag" type that will simplify the tag-handling portion of the alignment API.

--------

Those are the main changes that will necessitate changes to existing source code and build systems. Other immediate features on the roadmap will include:

  - exposing raw file offsets (seek/tell) via BamReader to allow intermediate/advanced developers to implement customized indexing schemes.
  - making BamReader actually copy-able 
  - adding an "iterator"-stye region fetch to BamReader
  - moving some of the toolkit functionality into the BamTools::Algorithms namespace to expose them to client code
  - adding unit tests to the repo for tinkering developers

Some of these listed here may actually appear before v3.0 since they simply add, rather than modify existing, functionality.

--------

I do apologize for the recent neglect in maintenance - wrapping up my PhD as we speak. After that, the job I have lined up does include BamTools upkeep, so I will definitely be showing it some love here in the near future. I've got some good ideas on where to take BamTools next, so keep an eye out for the changes I've outlined. 

I'll be adding a "release candidate" branch to the repo once I get close to the v3.0 release. So you guys will have a chance to try it out and give feedback before it goes live on the official master branch. 

I welcome any further suggestions; feel free to email me personally (derekw...@gmail.com) so we don't spam the list too much.

Thanks again,
  - Derek


To unsubscribe from this group and stop receiving emails from it, send an email to bamtools-use...@googlegroups.com.

Tonatiuh Pena Centeno

unread,
Oct 9, 2014, 3:04:17 AM10/9/14
to bamtoo...@googlegroups.com
Dear Derek,

is there a tentative date for the release of v3.0?

Thanks,

Tonatiuh

Karel Břinda

unread,
Oct 27, 2014, 1:06:13 PM10/27/14
to bamtoo...@googlegroups.com
Hi Derek,

thank you for your answer. Maybe it would be useful to add some information to the documentation about how to currently use BamTools with cmake in own projects. After some experiments, I found this way as the most straightforward (assuming that BamTools are in ./bamtools/):

1) Create script correct_bamtools_cmake.sh

#! /usr/bin/env bash
norm=./bamtools/CMakeLists.txt
back=./bamtools/backup_CMakeLists.txt
if [ ! -f $back ]; 
then
        mv $norm $back
fi
cat $back | sed 's/FATAL_ERROR//g' > $norm

2) Add these lines to own CMakeLists.txt:

exec_program( correct_bamtools_cmake.sh )
add_subdirectory( bamtools )
include_directories ( bamtools/src )
target_link_libraries( MY_PROJECT BamTools )


Best regards

Karel





--
You received this message because you are subscribed to a topic in the Google Groups "bamtools-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bamtools-user/g3NVUy3kBBw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bamtools-use...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages