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 boost, they won't even investigate and think to add boost as a requirement. Maybe I'm not giving them enough credit :) Or maybe I should just pester the major package maintainers to make sure they realize after this goes in. There is one issue that remains around this that I can think of: The GitHub builders. Do we want to add boost there so they test building maestro and running the tests? Or do you run multiple builders with different settings? I'm happy to help there, but if there's someone who owns this for you, I'm also happy to just raise the flag and move on. Pat PS - one additional heads up: this summer of code project <http://wiki.openchemistry.org/GSoC_Ideas_2019#Project:_Integrate_CoordGen_library> will add dependencies to maeparser/Boost, and I think some Qt dependencies. On Tue, 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://lists.sourceforge.net/lists/listinfo/openbabel-devel
