standard build using GNU autotools

[wookietreiber]

With this PR sickle can now be built, tested and deployed using standard GNU autotools.

Run ./bootstrap to generate configure and others and then the following will install sickle into /usr/bin/sickle:

./configure --prefix=/usr
make
make install

I have also added two tests to what I could make of the files you had in the test directory.

You can still create a standard release tarball using make dist.

If you have questions about GNU autotools, just let me know. The required autoconf version could maybe be lowered in configure.ac, try testing it if you have an older one.

[tsibley]

Out of curiosity, what benefits does GNU autotools produce for something as simple and small as sickle?

[wookietreiber]

What you get for free with a build tool like GNU autotools is the generated configure script checking that all the dependencies are met (like zlib). This is important when you are working with non-default install prefixes, e.g. instead of installing zlib to /usr installing it to /usr/local/zlib/version-name. I do this regularly on an HPC cluster I administrate because we need to support multiple versions of the same software at the same time. Thus, no default installation prefix is possible.

Also, configure lets you tweak many settings without hacking Makefile, e.g. your custom CFLAGS, CPPFLAGS, etc. are passed through to each compilation task. This is important if you have specific compiler instructions you want to pass through. My personal ones look like these (exported in my shell environment):

export CFLAGS="-march=native -mfpmath=sse -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"

GNU autotools automatically picks these up and passes them through. If you care just a little bit about performance, you should set your machine-specific compiler optimization flags in CFLAGS (for c), CXXFLAGS (for c++), etc. With a manually written Makefile, it is much harder to get passing these through right, so the build tool in this case definitely prevents headaches.

The benefits above are customization oriented, but there is more:

If you think bigger, what you sooner or later want in any project is some sort of test suite, like I started to prepare in this PR. This can go from really dumb stuff, like I did, with the program runs successfully for simple input data, to the valgrind checks I included to make sure there are no memory leaks, up to really useful regression testing for all the issues that have been reported, like the test in #33 does for #32. You can integrate these tests manually, however, it is much easier with a build tool like autotools, because all the infrastructure is already provided to automatically run the tests, provide a log, etc.

Another benefit I can think of right now, which might come in handy in the near future, is handling optional features, like parallelism. I just see the pthreads branch (don't know what it's actually for), but pthreads is one way to parallelise. You may also do this with OpenMP or MPI, if suitable for the algorithm. Letting the user choose which one via configure is very convenient, some users don't want it at all for whatever use-case they have. I have seen other projects, which have a different Makefile for each way to parallelize or not, which is just tedious to maintain as a developer and also bit rot is inevitable.

With such things in mind for the future of a software project that is small at the moment, it is now, since there is not much complexity in building it, relatively easy to port the build from a standalone Makefile to a build tool like autotools, rather than in the future, when it won't be that easy anymore.

In conclusion, yes, at the moment the benefits are comparatively small, but thinking ahead, it might just be worth it.