you should be able to use SIRF include files that are located elsewhere. At present you specify include_directories as being in the current directory (where the source is).

set(SIRF_SOURCE "${CMAKE_SOURCE_DIR}" CACHE PATH "Location of the SIRF source")
include_directories(${SIRF_SOURCE}/src/common/include/)

and whatever you need.

At some point, you will be using an installed SIRF, in which case all SIRF include files will be in one location, but you can then just modify the above accordingly.

SWIG 4.0 can parse doxygen comments in the C++ file and pass them on to Python. It even handles LaTex formulas as far as I can see.

Something like this in the CMakeLists.txt (but I didn't check the if statement)

  if (SWIG_VERSION VERSION_GREATER_OR_EQUAL 4.0.0)
      SET(CMAKE_SWIG_FLAGS -doxygen)
  endif()

we need to be able to copy the files after building to a particular location. You can probably just copy the following lines from STIR
https://github.com/UCL/STIR/blob/40545147179fbe2b1131679672375cc91a39ab55/src/swig/CMakeLists.txt#L116-L118
obviously adjusting the name (stir) to your project.

After inserting those, if you run CMake, you should have a PYTHON_DEST variable in the list of things that you can set. You can then set it to where you want it. As it's a CACHED variable, it will remember what you set for next time, such that you have to do this only once.

would you still be able to add license info? Ideally you would use the Apache 2.0 license.

1. create a LICENSE.txt file (copy of https://github.com/SyneRBI/SIRF/blob/master/LICENSE.txt without the first paragraph)
2. create a NOTICE.txt file (see example https://github.com/SyneRBI/SIRF/blob/master/NOTICE.txt), which in this case I believe should only mention you and me. My copyright is owned by UCL. Yours is probably owned by yourself.

As clone() returns a std::unique_ptr, which SWIG cannot handle yet, we have to work-around it.

A first step could be like

%ignore *::clone()
%extend sirf::DataContainer
{
  DataContainer * my_clone() const
  { 
    return clone().get();
  }
}

%newobject *::my_clone();

Lines 57 to 66 from ...\sources\SIRF\examples\Python\PET\fbp2d_reconstruction.py can be used as a starting point with FBP2D reconstruction script.

The wrapping works at the moment, but people will expect the objects to act Python-like. For instance

a.items()
# vs Python-style:
len(a)

This can be achieved in 2 ways I believe

• using %rename to rename items into __len__
• using %extend to add __len__. You can see an example of this in https://github.com/UCL/STIR/blob/master/src/swig/stir.i#L889-L908

Next step would be to do some arithmetic operations:

 a.multiply(b,c)
 #vs Python-style:
 a = b*c

Similarly, you can try something like

• using %rename to rename multiply to operator*
• using %extend to add operator*.

Some (not so easy) doc on this is http://swig.sourceforge.net/Doc4.0/Python.html#Python_builtin_overloads

I think the %rename options are probably best.

would you be able to clarify the (almost?) duplication between the files in the main folder and the swigtest folder? I didn't check yet, but they same virtually the same.

There are a few functions/classes that are currently called differently after SWIG compared to SIRF. Examples are

• my_clone -> clone (can probably just be called like that in the .i)
• from_array -> fill. Of course, there's a fill(float) already, but it looks like SWIG will take care of checking the argument types. You should show this by making your test script call both fill(1.1) and fill(some_ndarray). You could even check the generated wrapper if you feel like it. If this works, it would be worth commenting on in the report
• xSTIR_FBP2DReconstruction -> FBP2DReconstructor I believe (this would need a %rename)

As @evgueni-ovtchinnikov added PETAcquisitionModelUsingRayTracingMatrix to C++ in SyneRBI/SIRF@6eb1bc4, it'll probably need to be removed from test.i

Like the std_string.i, you probably will need to add a few others, maybe only std_vector.i and std_shared_ptr.i, see
http://www.swig.org/Doc4.0/Library.html#Library_stl_cpp_library

In particular, the shared_ptr will be important. This is a bit more work than just including that file, see
http://www.swig.org/Doc4.0/Library.html#Library_std_shared_ptr
essentially

%include <std_shared_ptr.i>
%shared_ptr(sirf::DataContainer)
%shared_ptr(sirf::ImageData)
Etc
%include "sirf/common/DataContainer.h"
Etc