Possibility of having a single header to include

[johnlees]

We are using Seqan3 in a couple of projects, and it is generally working nicely. However, one issue we have is that over time our builds start failing when they pull in a newer version of Seqan3 which has different header file. One example is #include <seqan3/range/views/all.hpp> in v3.0.3 moving to #include <seqan3/search/views/all.hpp> in v3.1.0.

I know that the v3.0.x releases don't promise a stable API, but I was wondering if it might be possible to have a more general header to include which then includes all headers from the library (as is done in e.g. Eigen3)? This would also help with the issue that we currently include 9 header files from seqan3, all of which could change (and it's hard as an external user to remember which are necessary).

Thank you!

[smehringer]

Hi @johnlees,

we're happy to hear you are using Seqan3!

Sorry about moving quite a lot of headers. Good news is that it won't happen this extensively anymore. If you are heaving trouble updating your seqan3 version feel free to report problems. We're happy to help.

We will discuss adding a seqan3/all.hpp that includes the whole library next Monday and report back to you shortly.

[johnlees]

Thanks for the quick reply! We've got our build working again without too much trouble, but this would be useful if it fits into your plans. For reference, this is what our current includes look like: https://github.com/johnlees/unitig-caller/blob/master/src/map_strings.hpp#L29-L38

[smehringer]

Thanks for the insight!

Side note: I saw that you are using bifrost. We are currently developing the seqan3::interleaved_bloomfilter which if I am not mistaken can compete with bifrost and shows superior performance. Take a look at our app raptor that internally uses the IBF if you are interested (https://www.cell.com/iscience/pdf/S2589-0042(21)00750-1.pdf).

[SGSSGene]

Hi @johnlees

We looked at our tool https://github.com/seqan/raptor and checked what would happen to compile time of different cpp files if we they used a single include:

	currently	single header
build/raptor_build.cpp	10.5s	15.5s
raptor.cpp	3.8s	11.3s
search/search_ibf.cpp	11.7s	17.8s

We see an increase of 5-7s for every single compilation unit. We decided this is to much and using a single header is not recommended, and don't want to encourage this.

Of course we also understand that maybe for your usecase that doesn't matter at all or you simply don't care. In that case you could create a seqan3.h file in your project and populate it with:

(
  cd <seqan3_repo>/seqan3/include/ # replace <seqan3_repo> with your path to it
  echo "#pragma once\n"
  find . | grep .hpp\$ | cut -b 3- | awk '{ print "#include <"$1">" }' >
) > seqan3.h # adjust this file if you want something else

Now you can include "seqan.h" in your project and only need to update seqan3.h every time you update your seqan3 dependency.

[johnlees]

Thanks for looking into this, and for your thoughtful reply!