Comment 3 for bug 1488211

Thanks heaps for helping us out here guys!

I agree that the dynamic build script hackery adds complexity and makes it harder for people to figure out what's wrong when something won't package correctly. On the other hand, the gcc5 situation is rather unusual. Long term, the cost of having to apply every change to two trees and getting both of them landed is large. (And, sooner or later, someone will make a mistake there too, accidentally causing the trees to diverge.)

But, one other thing that is useful with generated debian files (even without needing to land things twice): the version info for the library is present in a surprisingly large number of places:

- In CMakeLists.txt, so we can set library name and soname

- In another CMakeLists.txt, so we can install headers to the correct path

- In another CMakeLists.txt, for the pkgconfig file

Because we install two libraries, multiply that by two.

The we have all the install files, symbols files, and control (and maybe on or two I forgot). The point is that if the version number has to change, there is a surprisingly large number places where one has to go change things, and it's easy to get that wrong. With the generated debian approach, I have the version number in exactly one place in a file, and everything else pulls it from there and does the right thing automatically.

This isn't worth doing for a small project, or a project that doesn't ship libraries. But for something our size, I think that's a win.