Openpmd-api: Remove Boost Dependency

[ax3l]

Please replace boost MPL lists with mp11 lists.
Requires Boost 1.66.0+

Update: oh wait, that is only boost variant you are controlling, right?

Anyway, careful with global BOOST_MPL_ defines in-code! Better set them in CMake as PUBLIC target properties since downstream code might use BOOST_MPL as well! (and the compile-time impact of BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS might be big).

There are also other C++11 libs of variant that we could consider to use in order to avoid Boost::MPL modifications.

Possible candidates for C++11 variants:

• https://github.com/mpark/variant (preferred)
• https://github.com/mapbox/variant

Possible replacements for C++11 filesystem (we require directory traversal, listing and creation):

• https://github.com/cginternals/cppfs
• https://github.com/wjakob/filesystem
• http://www.martinbroadhurst.com/list-the-files-in-a-directory-in-c.html
• https://github.com/cxong/tinydir
• https://github.com/LLNL/conduit/blob/master/src/libs/conduit/conduit_utils.cpp
• https://github.com/PollardBanknote/cppbackport

[C0nsultant]

Yes, those #defines are there to increase the default limit of MPL lists.

Agreed, it is very hacky and unelegant. It it mainly in there since we did have the Boost dependency and I did not want to bother implementing a varaidic/any from scratch.

Agreed, this should be replaced to get rid of even more dependence on Boost in the future.

[ax3l]

The last thing that is left is boost::filesystem (boost/filesystem.hpp).

The functionality we need from it is (@C0nsultant pls append if I missed something):

• path (object)
• exists (dir, file)
• directory_iterator
• create_directories
• remove (file)

(all of this: Linux/Unix, OSX, Windows)

[C0nsultant]

That should be it. To put it in terms less specific to Boost:

• directory existence check
• directory creation
• directory content listing
• file existence check
• file deletion

[ax3l]

I think we can put this in a single auxiliary/ header + source file. @C0nsultant do you want to try implementing the 5 methods? I think it's not worth pulling a dependency and we can just take what we need.

[C0nsultant]

We could potentially build a very slim backport of std::filesystem that offers the few functions we need. Then we can drop-in std::filesystem the same way as variant if the library is being built with C++17.

As a sidenote, this also means we have to assume POSIX availability for non-Windows systems.

[ax3l]

I thought so first as well, but alone the implementation of path objects, etc. is probably not worth it outside of pure curiosity. Since we don't need anything recursive I think the 5 slim functions above will be enough.

[C0nsultant]

It's on my list.