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 important.
> On Jun 11, 2019, at 5:32 AM, Noel O'Boyle <baoille...@gmail.com> wrote:
> 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)
Perhaps package maintainers can chime in, but IIRC that C++11 was supported
back in GCC-4.8.0 from 2013. I don't personally see a problem with that going
forward.
> Turning it around, is it reasonable to add a requirement for Boost just to
> read in a particular file format? I'm happy to work with you to remove Boost
> from your codebase if that would help.
I mentioned this to Patrick because we have plenty of formats that are turned
on or off based on build support (XML, JSON, Eigen, Cairo, etc.)
My personal opinion would be to have a Cmake test for Boost and compile the
maeparser code conditional on that. At one point we had a boost check (for
shared_ptr support) and it's definitely how things are organized for formats:
> if(MSVC OR HAVE_REGEX_H)
> …
> endif(MSVC OR HAVE_REGEX_H)
>
> if(WITH_JSON)
(etc).
From Patrick:
> my worry there is that package maintainers would default to leaving it off
> and not add boost as a requirement, effectively disabling this feature for
> most users.
I don't think we can control what package maintainers do. But if you think
package maintainers are going to ignore features with Boost, that tells me a
lot..
For now, I'm fine with Boost as an optional dependency for MAE compilation.
-Geoff
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
