Thanks all for the lively conversation. I've updated the pull request to
check for boost and only build maeparser if it's available (printing to the
user saying it's skipping maeparser if it's not available). I'll probably
ping a few package maintainers about making sure to add a boost
I agree with Geoff for all the reasons listed. Not being able to use boost is a
constant annoyance. Making any boost dependent features conditional on boost
available in cmake seems like a great compromise that will provide the feature
to 99% of users while imposing a small burden on the
I would be in favor of making boost a default that has to be explicitly
disabled with a cmake define (but still require building w/o boost to work).
The failure message would tell the user what they have to pass to disable the
boost requirement.
David Koes
Assistant Professor
Computational &
OK Geoff - sounds good, I'll change the code so that it checks for boost
and only turns maeparser on if boost is present.
To clarify my worries about package maintainers, it's not that they'd have
a problem with turning boost on, it's just that if we don't make the
*default* build hard fail w/o
To start out, I'll emphasize that OB has been a default package on several
intentionally slow-to-upgrade distros. I'm not surprised to access new
supercomputing resources to find Open Babel 2.3.2 or something similarly old.
As a result, I do think backwards compatibility for compilers is
Hi Noel - after discussing it more, I think we're pretty committed to
having a Boost dependency in maeparser. Even with our current boost
requirement, maeparser already compiles on where we "draw the line" for old
platforms: CentOS 6, released 8 years ago, the oldest CentOS still getting
Well, personally, I don't want that dependency. It would mean dropping
support for particular legacy OSes, where Open Babel has compiled without
trouble until now (similarly the CXX11 requrest). As I see it, users of
Open Babel will see no benefit from us using Boost, but will find it more
