Re: [reSIProcate] Build systems.
I'm keen on the idea of having a debian package. Inline ...
On 3/9/06 12:00 PM, "Daniel Pocock" <daniel@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> 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.
makes sense - that would all be good
>
>>> 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.
We have shared libraries and versioning. That's where I get lost on what we
need here (and I can believe we need more, I'm just not sure what)
>
>>> 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.
yep - I agree
>
> 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
>
In the past, all the problems came up when people used options that required
you to use the same option on a program that *used* the library as the
library was compiled with. I think we could not use any of these by default.
> 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.
>
Excellent
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel