Cleanup the 3rd party support code

[eugenwintersberger]

The current situation

• all support for 3rd party libraries (including h5py or even the C++ standard library) lives in the source directories of the main library
• some of the code is even included in header files required by the core library
• the header files with the support data structures are included in the default hdf5.hpp file and thus always active without providing the user a chance to remove them

Suggested fixes

• create a new hierarchy of directories below src/h5cpp/support
• each supported library gets s subdirectory there. For instance: src/h5cpp/support/stl or src/h5cpp/support/h5py
• the same structure should be provided for the tests below test/support
  Users who want to have support for STL data types can than easily add

#include <h5cpp/support/stl/vector.hpp>
#include <h5cpp/support/stl/string.hpp>

This would give the user a way to provide its own std::vector integration if he needs this.

How to get there

• I would first start with moving the existing code and test the new structure
• create a simple manual for developers how to integrate 3rd party support code

Once this is done (I hope during Christmas) it would be nice if others join in providing support for other 3rd party libraries.

[planetmarshall]

Up to you as the maintainer but I might suggest contrib rather than support. contrib is a fairly common folder name for this kind of thing.

[eugenwintersberger]

@planetmarshall contrib is definitely a much better choice.

[eugenwintersberger]

Ok. For STL my approach seems to work. However, there is some tight coupling between STL strings, vectors and HDF5 attributes. This is something I have to think about but this should not stop us from moving on.
@jkotan A question for Jan: is the EBool something which is required for h5py? Somehow I forgot why this was introduced.

[jkotan]

@jkotan A question for Jan: is the EBool something which is required for h5py? Somehow I forgot why this was introduced.

Hi Eugen, the story is about NX_BOALEAN in NeXus.

At the beginning in the old libpniio versions to stores NX_BOOLEAN type variables DESY was used a predefined hdf5 integer type (like in C language). The problem is that when you read such a bool variable you cannot find if it is really boolean or integer one (unless you defined additional (optional) attribute type which discribes the type).

In NeXus format mapping to hdf5 format is not strictly defined i.e.

NX_BOOLEAN  true/false value ( true | 1 | false | 0 )

so it can be anything which can be mapped to true and false values.
Therefore, we started to search for another option to store NX_BOOLEAN types. We didn't want to reinvent the wheel so we decided to adopt h5py a convention which stored python bool type variables in hdf5 Enum with two values FALSE and TRUE. In our case it is EBool. Moreover, a lot of people use h5py to create nexus files even they don't know they use enums for store bool type variables.
Thus, our newer versions of libpniio as well as libpninexus library so that our newer detector servers and python-pninexus maps NeXus NX_BOOLEAN and bool c++/python types to the EBool enum.
So for DESY it is standard way of storing bool type variables.
But if you want to read back bool variables written by h5py you also need EBool. Otherwise you will read a variable to general enum type which you need to interpret by youself .

[eugenwintersberger]

@jkotan would it be ok for you if I move this to a contrib/nexus directory?