[reSIProcate] Build systems.

[Daniel Pocock]

>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.