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 requirement when/if this is eventually released.
Pat On Tue, Jun 11, 2019 at 1:39 PM Koes, David <dk...@pitt.edu> wrote: > 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 > contributor (but less of a burden than having to reimplement boost > features). > > I would like the policy to change from “don’t use boost” to “if you use > boost, make sure compilation of your code is guarded in cmake”. > > David Koes > > Assistant Professor > Computational & Systems Biology > University of Pittsburgh > > > On Jun 11, 2019, at 10:14 AM, Geoffrey Hutchison < > geoff.hutchi...@gmail.com> wrote: > > 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://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fopenbabel-devel&data=02%7C01%7Cdkoes%40pitt.edu%7C68edfea1b7e54f7b0e5408d6ee771c1c%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1%7C0%7C636958592679903209&sdata=aMfq4jNyCS1oGFTgR4uBbhmMrw8NiJKeUB2f3b8vLe4%3D&reserved=0 > > > _______________________________________________ > OpenBabel-Devel mailing list > OpenBabel-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbabel-devel >
_______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
