Remove dependence on BOOST

[memmett]

In the spirit of making PFASST++ easier to use and install for end users, I think it would be good to remove as many dependencies as possible. Currently we use Boost's "program options" module to take care of parsing command line options and reading configuration files [see also note 1].

This results in two things:

1. Users need to add a dependency on Boost to their software.
2. Users need to link to 'boost_program_options', which is the only library that the core of PFASST relies on (ie, aside from 'boost_program_options', PFASST is a header only).

I have implemented rudimentary command line option parsing without using Boost. It isn't as slick/flexible as the Boost solution, but it is A LOT lighter weight. Is there support for this effort?

Notes:

1. There are few other places that we Boost, but these are fairly minor/trivial and would be easy to resolve if we dropped Boost.

[torbjoernk]

I agree, that having to pull in Boost only for the cmd parameter parsing is a little overload.

@memmett have you looked at docopt before rolling your own parsing? I'm using that for some of my Python projects and it's really neat and easy. The C++ port shouldn't be too hard to use either. We can pull it in via CMake's ExternalProject. By default it builds as a static library. In our case this should only require a build dependency we could easily handle via CMake and the users don't have to link and install it manually. Pretty much everything under the hood same as Eigen.

The other uses of Boost are the type-aware math constants and pre-computed expressions (pi^2 etc.). These are header only and shouldn't be of any problem for any users.

[pancetta]

Since I had to fiddle around with deal.ii, I can report that they have certain dependencies (like petsc) which are not required to compile and use the software (to some extend) but which make life easier/better. Can we keep Boost as optional dependency? If people want to use it, fine, and if not, fine as well. In the latter case, parsing command line options will not work out of the box... what do you think?

[memmett]

@torbjoernk Hadn't thought of docopt for C++! That might be a good fit. I'll take a look and maybe make a proof of concept on a branch. Also @pancetta, having certain features disabled if there are libraries missing is a good idea too -- something to keep in mind.

PS, @torbjoernk if you like docopt for Python, check out 'click' (on pocoo.org).

[torbjoernk]

So I had a little deeper dive into docopt.cpp as a replacement for boost::program_options. And a two significant problems evolved:

1. all passed and parsed values are accessible only as std::string
2. I couldn't come up with an easy way of consecutively add additional arguments as it is currently done (first general arguments from the base, then each component and example can add it's own parameters before constructing the actual parser)

With regards to point 1, the nice thing about boost::program_options is the possibility to have it safely cast the parameters to predefined types. This is a very powerful feature and very C++-ish. I love that. IIRC it relies on boost::lexical_cast. Having to role that casting safely on our own is a big pain in the b**t.

The stepwise addition of different parameters - together with their desired type - as well as the possibility to group them into semantic groups, is a huge win from my point of view. docopt.cpp expects a single complete usage and options description string. We could role our own construction method for that, but that would introduce another layer of complexity we have to deal with. I really don't like that.

To conclude, though I really see and understand your point of dropping Boost as a dependency, I don't see a nice and maintainable way of keeping the same level of convenience. Why is it so bad having Boost as a dependency altogether? Most C++ projects already depend on some parts of Boost. Do you know of any system, which does not provide an acceptable version of Boost? We can probably drop the requirement for 1.53.0 as I couldn't find a place where we actually use boost::multiprecision in the core library.

[memmett]

Thanks for looking into docopt.

Maybe we can cherry pick a few header-only things from Boost (like lexical_cast) and roll our own option database instead of requiring linking in program_options. I will take a stab at this...

[memmett]

Closed by #244.