Paul Querna wrote:
Joe Orton wrote:
On Wed, Feb 18, 2009 at 10:00:49AM +0100, Mladen Turk wrote:
Joe Orton wrote:
So you really need a hack to the configure script which introduces a
new way to break ABI compatibility with the standard build, just so
you can avoid copying some symlinks in an obtuse distribution
mechanism? I don't see it.
First of all it's not a hack.
It's a perfectly legitimate way how you can build a shared library.
Any other discussion would only lead to philosophical and
political rather then technical reasons.
It's off by default, and if you don't need it, don't use it.
If you don't have any technical justification for this other than "it
lets me avoid copying a symlink" then I'm -1 on this change:
1) A non-versioned library build has a different ABI to the standard
build, because the library SONAME changes.
2) Ballooning the number of possible APR ABIs is bad.
3) It is trivially simple to work around the problem of having to copy
symlinks without adding complexity to the APR build system.
We discuss changes on their technical merits. Saying "it's perfectly
legitimate" doesn't add much to that debate. It would be "perfectly
legitimate" to introduce a configure switch to make the library SONAME
be "libfluffy-pink-clouds-1.so"; no laws would be broken that I'm
aware of.
+1, I agree with Joe on this. This switch should not be present.
OK. I've remove it,
although still don't understand why something optional is
such a big deal, namely because it doesn't change anything
regarding default build.
If
you are bundling up a custom application, you can easily add some later
shell script to move around files however you want them to be called.
It's not that easy. It requires patching the configure.in,
but we'll have to live with that. The point is that moving isn't
enough. One needs to rewrite the apr-config and .lai file as well,
so making a patch to configure.in is much easier.
Regards
--
^(TM)
