Re: [reSIProcate] Build systems.
So the idea of having a binary call to get the version number seems like
good idea. How about making it so that unless someone has very weird needs,
they all compile the library with the same options. If people compile the
library with the "use Fortran stack calling conventions" then try to link
without using this option, I have very little sympathy. This is just not a
real problem. If people install different .h file than the library files on
their machine, well, what do other software projects do with this. I suspect
that the answer is not much. If I use the .h file from openssl 1.1 and use
the library from 1.2, bad stuff happens. Most people don't seem to find this
a problem.
I think this is unlikely to eventuate, particularly in packaged
environments. E.g. on Debian, there will probably be a `libresip-dev'
package that contains static libs and headers, and a regular `libresip'
package that contains the shared libraries. The packages will depend on
each other, so dpkg (Debian's package installation system) won't let
someone install mismatched versions.
It's also worth noting that in an environment like Debian, resip will
probably start off in the `unstable' area, where only the
confident/brave/reckless users/developers are likely to find it. So we
can keep on modifying the headers and not worrying about breaking other
peoples applications, because anyone who run's an OS that's labelled
`unstable' should expect that kind of stuff.
At some point, someone will probably take a snapshot of resip into the
`stable' distribution, and anyone who wants their app to be stable will
probably base their app on the headers in that snapshot.
We are close and it may well be that the fast-path to getting this is
to expand our current build system. That would be great.
I just worry that ABI versioning + dynamic libraries == 90% of what
autotools will do.
I have no idea what you are talking about here.
I think Alan's saying that, (hopefully) if we go through the pain of
getting autotools, then we won't have to make much extra effort to get
the ABI versioning and dynamic libs.
I just want a product we can package and have other applications use
if it's installed on a system.
Ok - that is a good goal. What are the problems in doing this today. If the
issue is that some people compile the library with foo-buffer-size=64 and
the applications needs to be compile the same, well, lets remove these
options. I will point out that a ton of other libraries make two version,
one with ssl and one without. My vote would be make just one version and
have it use ssl.
With a packaging system like Debian, developers will still be able to
get the source from SVN, combine it with the packaging scripts, and
build their own custom packages of the library with the compile time
options they desire. Therefore, there is little harm in choosing a set
of default options.
It is actually rather easy for someone to do. To give an example, I
recently did this:
apt-get source bind9
cd bind9...
.... install my own SDB driver, change makefiles
dpkg-buildpackage -rfakeroot
and ended up with a custom bind9 package with my sdb driver statically
linked (because it doesn't support dynamic at present). I could then
(after some gruelling testing) copy the package to all my production
servers.
I note that there has been a lot of activity on the Debian VoIP
maintainers mailing list lately, with other cool stuff like SER,
OpenSER, etc finding their way into the official distribution. If resip
can be tweaked to meet the packaging requirements, then I doubt it will
take long for the packages to become a reality.