Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doesn't work with libxml++2.40 #48

Open
osimola opened this issue Oct 23, 2019 · 2 comments
Open

Doesn't work with libxml++2.40 #48

osimola opened this issue Oct 23, 2019 · 2 comments
Assignees

Comments

@osimola
Copy link

osimola commented Oct 23, 2019

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
Copy link
Member

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.

@TinoDidriksen TinoDidriksen self-assigned this Oct 25, 2019
@osimola
Copy link
Author

osimola commented Oct 26, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants