packaging advice for the ismrmrd library

[Ghislain Vaillant <ghisvail@gmail.com>]

Hi everyone,

I am currently working on the debianization of the ISMRMRD library for
which I have filed an ITP here:
https://lists.debian.org/debian-devel/2013/12/msg00255.html

The library itself is a C++ implementation of a common MRI data storage
format, developed by a consensus of MRI reconstruction experts.

The library uses cmake as the build system, which is convenient to
package (makes the d/rules super simple). As far as the packaging of the
cpp-lib is concerned, I have got a working debianized package already,
which I am ready to submit.

However, the build system also produces the Python and Java wrappers
with SWIG and I am not quite sure how to handle this properly.

For Python, the current cmake only cares about python 2, whilst SWIG
could also be used to make the python 3 version. Besides, wrappers
should be built for all supported versions in Debian as the Debian
python policy states.

I am wondering what's the best option here. Here is so far what I am
thinking of:

- use a separate setup.py responsible for building the the python
wrapper only. Then, I am assuming I could use the existing dh_python
magic to produce the python 2 and 3 wrappers.

- modify the upstream cmake files to make separate python 2 and python 3
wrappers. I am not super familiar with cmake and, judging by the
non-conventional format of the build, i.e. everything is built in
$DESTDIR/ismrmrd/{include,lib...} and wrappers are put together with the
c-lib in $DESTDIR/ismrmrd/lib, I foresee potential name clashing between
python 2 and 3.

- maybe something else, but I am no expert in build systems...so please
be verbose in the explanation :)

Concerning Java, cmake produces a .jar file at $DESTDIR/ismrmrd/lib,
which should be enough shouldn't it ?


Any advice / contribution to the discussion on the best angle to
approach this would be welcome.

Cheers,
	Ghislain