SeqAn2 version check

[mariehoffmann]

Add seqan2 version check in build_system/seqan3-config.cmake. Some headers in seqan3 include seqan2 headers. When using seqan 2.2, you run into a bug (ambiguous usage of empty()), reported also here: rrwick/Porechop#76. Related bug was fixed somewhere between 2.2.0 and 2.4.0. With 2.4 you are on the save side.

[rrahn]

In seqan3 we don't include seqan2. It is only for the performance builds where we compare against seqan2 to evaluate possible performance regressions in some of the benchmarks. These tests only check if SeqAn was installed (can be found in the PATH environment or in the system's include paths). We could instead have the cmake file in the performance section try to detect seqan and require the version 2.4 there.

[smehringer]

We could instead have the cmake file in the performance section try to detect seqan and require the version 2.4 there.

sounds good

[h-2]

I think this is all a bit much. I don't want to clutter seqan3's build system with seqan2 stuff. The beauty of header-only libraries in combination with __has_include is that we can do everything from C++ and don't need extra tooling. If you think a version check is necessary you can do it via macro inside the code.
But performance checks are only performed by us and from my POV it is self-evident that if you want this very-optional-not-documented-for-the-devs-of-the-library feature you at least take the latest version!

[rrahn]

What is a bit much? It is one line in the cmake file of the performance builds. Nothing will be added to the seqan3 build system.

[mariehoffmann]

I assumed benchmarks are also interesting for app writers who want to figure out which approach out of many is the fastest. How do you infer from an ambiguous usage of 'empty' that seqan2 is not uptodate? It costs you some minutes or more in the best case, but saves it all with a simple check in the performance related cmake section. rrahn <notifications@github.com> schrieb am Di. 19. Feb. 2019 um 13:01:

What is a bit much? It is one line in the cmake file of the performance builds. Nothing will be added to the seqan3 build system. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#748 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwGAmMMztJ_6KD0hKOXMboC1irpc1Rdks5vO-e1gaJpZM4bBWfF> .

-- ~~~~ l><(((°> ~~~~~~~~~ IGB ~~~~~~~~~ <°)))><l ~~~~~~~ ┌┐┌┌─┐┬─┐┌┬┐┌─┐┌─┐┌┬┐┬ ┬ ┬─┐┌─┐┌─┐┌─┐┬─┐┌┬┐┌─┐ ││││ │├┬┘ ││├─┘├─┤ │ ├─┤ ├┬┘├┤ │ │ │├┬┘ ││└─┐ ┘└┘└─┘┴└──┴┘┴ ┴ ┴ ┴ ┴ ┴ ┴└─└─┘└─┘└─┘┴└──┴┘└─┘

[mariehoffmann]

Just to give an example, the anchor_block approach for sequence decoration uses a fixed block width whose optimal value is use-case and platform depending. The benchmark could be used to "learn" the optimal width. Marie Hoffmann <ozymandiaz147@googlemail.com> schrieb am Di. 19. Feb. 2019 um 17:24:

I assumed benchmarks are also interesting for app writers who want to figure out which approach out of many is the fastest. How do you infer from an ambiguous usage of 'empty' that seqan2 is not uptodate? It costs you some minutes or more in the best case, but saves it all with a simple check in the performance related cmake section. rrahn ***@***.***> schrieb am Di. 19. Feb. 2019 um 13:01: > What is a bit much? It is one line in the cmake file of the performance > builds. Nothing will be added to the seqan3 build system. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#748 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AEwGAmMMztJ_6KD0hKOXMboC1irpc1Rdks5vO-e1gaJpZM4bBWfF> > . > -- ~~~~ l><(((°> ~~~~~~~~~ IGB ~~~~~~~~~ <°)))><l ~~~~~~~ ┌┐┌┌─┐┬─┐┌┬┐┌─┐┌─┐┌┬┐┬ ┬ ┬─┐┌─┐┌─┐┌─┐┬─┐┌┬┐┌─┐ ││││ │├┬┘ ││├─┘├─┤ │ ├─┤ ├┬┘├┤ │ │ │├┬┘ ││└─┐ ┘└┘└─┘┴└──┴┘┴ ┴ ┴ ┴ ┴ ┴ ┴└─└─┘└─┘└─┘┴└──┴┘└─┘ --

~~~~ l><(((°> ~~~~~~~~~ IGB ~~~~~~~~~ <°)))><l ~~~~~~~ ┌┐┌┌─┐┬─┐┌┬┐┌─┐┌─┐┌┬┐┬ ┬ ┬─┐┌─┐┌─┐┌─┐┬─┐┌┬┐┌─┐ ││││ │├┬┘ ││├─┘├─┤ │ ├─┤ ├┬┘├┤ │ │ │├┬┘ ││└─┐ ┘└┘└─┘┴└──┴┘┴ ┴ ┴ ┴ ┴ ┴ ┴└─└─┘└─┘└─┘┴└──┴┘└─┘

[h-2]

What is a bit much? It is one line in the cmake file of the performance builds. Nothing will be added to the seqan3 build system.

I am pretty sure it is more than one line, but if you volunteer to do it, don't let me stop you.

I assumed benchmarks are also interesting for app writers who want to figure out which approach out of many is the fastest.

No, I think we should publish clear instructions (possibly with numbers) in the API documentation. App writers definitely should not have to run our benchmarks to figure out which types to use.

How do you infer from an ambiguous usage of 'empty' that seqan2 is not uptodate?

I don't know, maybe we just have a different approach. If I encounter a problem, but I know there are other people using this who apparently don't have this problem, the first thing I do is check if my software is up to date 🤓
(But I am used to broken system software from years of UNIX experience so that might not be representative)

Just to give an example, the anchor_block approach for sequence decoration uses a fixed block width whose optimal value is use-case and platform depending. The benchmark could be used to "learn" the optimal width.

I don't think this is feasible for our app developers. We need to figure out sensible default values and suggest very few, clear alternatives for selected scenarios, e.g The default block size is good for sequence lengths < 10.000. For longer sequences you should increase this value.
In the end app developers need to benchmark their own app that's much more relevant than SeqAn's micro-benchmark which are primarily there to track performance regressions (in our code or compilers).

[marehr]

I needed to adjust some stuff to make seqan2 iterators usable with ranges and introduced a seqan2 header file (only available for test files) in #755.

@h-2 This would solve this, but I'm not sure if you okay with this approach. If you have some suggestions, I'm happy to include them.