Generating the interface code for all versions of GSL from a single version is problematic

[djerius]

Currently a single version of the GSL headers is used to generate the SWIG interface code for all of the versions of GSL supported.

This is problematic, as there is a mismatch between the API's of the different versions. In later versions deprecated functions may be removed. If we use those headers, earlier versions will lose functionality.

Instead, I think that we should use the GSL headers for each specific version and commit those to the repository. We may need to regenerate them if we add missing functionality, but at the least we don't have to worry about incompatible API's.

[djerius]

This is causing another failure mode when additional routines in a GSL module are added in a later version of GSL. For example, the sparse matrix support in GSL v 2.2.1 added new routines. Code generated for v 2.0 and v 2.1 now contains wrappers for the new routines which do not exist in those versions, causing runtime undefined symbol errors (see https://travis-ci.org/leto/math--gsl/jobs/446986667)

[djerius]

Nope, that failure is caused by ver2func not being updated. Documentation is definitely needed for this part!

[djerius]

Currently a single version of the GSL headers is used to generate the SWIG interface code for all of the versions of GSL supported.

This is problematic, as there is a mismatch between the API's of the different versions. In later versions deprecated functions may be removed. If we use those headers, earlier versions will lose functionality.

Deprecated functions are handled via PR #158

[djerius]

After working with the codebase for a while, I now understand the tradeoffs better. The existing approach makes it easy to share code across multiple versions of GSL, at the cost of needing to keep track of which features are available in which version. Other than some hackery needed to handle changes in C structs, the approach is sound. I withdraw my uninformed objections.