Re: [reSIProcate] Build systems.
Hi,
On Thursday 09 March 2006 18:10, Alan Hawrylyshen wrote:
> I hate to raise this issue, but I think we have to. :-)
Definitely.
> There are a few people interested in packaging reSIProcate for
> distribution within a larger package framework, for example, the
> Debian project.
> In order to make this painless (or less painful), it would be great
> if reSIProcate had a few properties that it does not currently have:
>
> - Compile on all [project] supported architectures.
> - Build an installable library with version detection in the ABI for
> the library.
> - Create a site-local header file that encapsulates all configure
> options that affect the ABI.
> - Install cleanly from a simple 'make install' command.
>
> One of the ways we can make this work well, and I know we've tried it
> before, is to use the autotool suite. We received some fairly strong
> objections to this, and as I recall they were typically related to
> the pain involved in adding files if you wanted to work on the
> project in a major sense.
>
> I would like to solicit people's opinions on moving back to autotools
> vs extending our build system ourselves to support these simple
> requirements for packaging and better exposure (and releases) of the
> library. I dare say that right now we run very much as an
> experimental project and not as a packaged library.
>
> I welcome a transition to ABI versioning and proper installation
> support.
>
> I suspect that now our developer community is larger and more able to
> accommodate / maintain and extend autotools too. Therefore, if you
> have autotools experience, please take a moment to think this through
> and respond to the list. We'll all benefit from being able to
> evaluate the current state-of-the-community with respect to our
> skills and our goals at this time. I believe the community is much
> stronger than ever so we might be in a great position to make this
> change from 'project' to 'package'.
>
> Thanks very much I welcome all input on this topic,
I'm probably telling nobody something new if I'm voting for autotools support.
And I'm adding my comments here allthough I'm not a user or developer of
resiprocate.
I agree that maintaining autotools is a pain in the neck. But I think it pays
off.
One of my major reason for autotools was not mentioned so far: the detection
of optional or required external software.
It was my main reason to contribute to the autotools support of resiprocate,
because repro was not compiling on my Gentoo system because the Berkely DB
headers were hardcoded into repro with a different location.
From my experience it is far bigger pain to try to detect external software,
and maybe its versions, from a Makefile. If someone has a good and easy
solution for this problem without autotools I would undetermined what is the
better approach.
And in my opinion this argument gets even stronger if you want to support
multiple different architectures and operating systems where even the same
lib may be different.
Just my 2 cents
Nils