arb
arb copied to clipboard
flintlib
Header names -- too generic?
It was noticed recently that arb puts its headers directly in /whatever/include/, and some of them had short or generic names which are an invitation to conflicts with other packages at some point in the future.
Would it be possible to move them to a subdirectory? I thought perhaps /whatever/include/flint/arb/ would fit quite nicely, as it's a satellite library.
Yes, this has been noted before.
I would make it /include/arb rather than /include/flint/arb.
Backwards compatibility is an issue.
I proposed flint/arb/ because I feared arb/ could be too short...
Yes, that definitely breaks backwards compatibility (sagemath will have to cope with it).
Aren't filenames with a '-' looking for trouble?
Notice that with a pkgconfig file, there would be no backwards compatibility breakage...
I have no idea. What I can say is that there is a couple of folder with '-' in /usr/include on my box.
We now have a conflict with SnapPy, which has Dirichlet.h - and on case-insensitive systems, this conflicts with arb's dirichlet.h !
Well, you have to bite the bullet and move the headers to a meaningful location. I do not understand why
backward compatibility is a real problem, one can always add -I/usr/include/arb (or whatever) to the compiler flags, without changing the source code of an application calling arb.
It is a bit naive to assume that you can just squat the name of a famous mathematician for a header name...
@NathanDunfield
I agree this needs to be done. Who's willing to make a pull request? I think I know how to patch the makefile, but the CMake build has to be patched too.
I do not understand why backward compatibility is a real problem
The problem with breaking backward compatibility is that downstream projects have to be patched. Breakage is breakage whether or not the patch is trivial. Downstream maintainers will have to write, test and apply the right patch for their own setting, which could be hours of work (I've wasted many days of my life trying to do completely trivial things). It will take months or years for changes to ripple through the dependency chain and package managers before which the new version is consistently standard... I've sometimes found myself on systems with packages that are 10 years out of date. Some downstream projects will need hacks to support both old and new versions. Some maintainers will not have time or interest to do it, resulting in permanent breakage (consider, in particular, academic projects with a single author who has more pressing responsibilities writing papers, teaching and sitting in committees -- this is how such projects bit-rot). In short, backward compatibility is a huge problem outside of a tightly controlled development environment. But if it's necessary to break it, then better sooner than later for precisely this reason.
This is yet another reason to have pkg-config support. With it at place, and properly used by downstream, moving headers becomes a non-issue, as the needed cflags etc are provided then. I propose this to be fixed too here.
I'll look at the cmake support - it is probably very easy to specify a sub-directory to install headers to.
What about tests - do tests use the installed location?
and properly used by downstream
That is one massive assumption :-)
What about tests - do tests use the installed location?
No.