search

samtools / htscodecs

Custom compression for CRAM and others.
Other
30 stars 18 forks source link

Do not build tests by default. #120

Closed teo-tsirpanis closed 5 months ago

teo-tsirpanis commented 5 months ago

This PR updates tests/Makefile.am to not build the tests by default.

It will be useful to save time when building htscodecs for non-development purposes.

daviesrob commented 5 months ago

I'm not sure if there's much benefit to this, given that the test programs only take a couple of seconds to build. However, if you really want to do this, a better way would be to change noinst_PROGRAMS to check_PROGRAMS in tests/Makefile.am so that the tests are only built if you run make check.

teo-tsirpanis commented 5 months ago

That's a lot simpler, thanks! Yeah there's not much benefit to it; I'm mostly doing it to get my feet wet with autotools.

jkbonfield commented 5 months ago

I'm in two minds about this as it currently stands.

If I'm modifying something, I routinely do a rebuild and then run a specific test program, maybe benchmarking it. I generally don't want to have to do a make check to build and do all the tests first. It would be nice to be able to build the test binaries without running the tests. It'll get a full "make check" at some point too, but it's not routinely in my edit-build-experiment cycle.

Of course I can do something like this:

# simulate modifying some code
touch htscodecs/fqzcomp_qual.c 

# Rebuild the library and the one affected bit of test tooling.
make && (cd tests;make fqzcomp_qual)

It works, but it's more faff than just the make I would have done in the past. (Although faster as it's not rebuilding all the other test tools which would previously want to rebuild as the library has changed.)

It's rather swings and roundabouts.

Maybe we can do some middle ground of a make target which builds the tests without executing the test suite itself. This can be particularly useful when enabling things like address sanitizer where running the full set of tests could be tediously slow. Or (more likely) I'd just do a "make" and hit control-C at some point!