Doesn't work with libxml++2.40

[osimola]

While trying to add new release to homebrew, I found that the code does not even build on OS X. This is because it sets compiler standard to c++20, and the code uses libxml++2 which in turn uses std::auto_ptr, which was deprecated in c++11 and removed in c++17. Standards-compliant compiler will not compile the code, unless standard is dropped to c++14 or c++11. It seems that the code builds fine as c++11 and no newer language features are used.

[TinoDidriksen]

Known issue with 3rd party XML libraries that nobody has wanted to fix. See #21 and #22 - currently "solved" with --without-libxmlpp --without-tinyxml2.

Maybe I should change the default to disable all external XML library support, until someone wants to add support for newer ones. I'll think it over this weekend - heavily leaning towards yes.

And to continue #41 here so we don't pollute a closed PR:

hfst-ospell builds with all current distro compilers with all the C++11 through C++20 versions. XML library support is not needed, and all our provided packages for Debian, Ubuntu, Fedora, CentOS, OpenSUSE, Windows, and macOS are built without XML libraries.

I would argue hfst-ospell's bitrot was fixed - there's 3rd party library bitrot, which we don't care about since we have a workaround.

As for C++ ABI, you're right no current compiler varies the ABI based on -std. But the stdlib API does change, which the flags catch. I have fixed a lot of issues in other projects because the highest C++ standard flag caught them early.

Anyway, we're in IRC Freenode #hfst if you want to discuss such things.

[osimola]

In my opinion support for libraries that can't be even compiled should be removed. Supporting obsoleted libraries is a form of bit rot in itself. The problem with removing XML support is that tests seem to depend on it.

As a professional software engineer, I have never encountered the idea that a program would benefit from being built with multiple different language standards. The common practice is to target a single standard and rewrite deprecated parts as moving to new standard. For finding problems in the code, static analysis tools such as SonarQube and automatic testing are a good option.

Can you explain how exactly -std option catches ABI changes?