Justin Erenkrantz wrote:
> On 7/15/06, Max Bowsher <maxb1@ukf.net> wrote:
>> Oh. I think we need a third party to intervene here - I think its pretty
>> clear we are never going to reach an agreement just between the two of
>> us.
>>
>> To my perspective, the above usage is just taking advantage of a bug.
>> I note that autogen.sh only buildconfs apr and apr-util - which is
>> inconsistent, as it doesn't try to handle neon.
>
> I don't think I have presented anything other than actual arguments
> against the change: we have supported this setup for years and we
> shouldn't break things silently. How am I being unreasonable? I
> don't view changing our INSTALL requirements as something that should
> be done hastily.
>
> The responses have been that this code is "long obsolete" and a "bug"
> - neither of which are true statements - it was intentional (present
> since at least r1) and worked just fine until this change was made. I
> suggested one such fix to resolve my veto. If you don't like that
> suggestion, then you are more than welcome to come up with an
> alternative to resolve it.
>
> Back to the matter at hand: on second thought, I do think we may want
> to keep this code even if it's not a SVN checkout because of the
> impact this has for people using SVN releases with bugs in autoconf
> and libtool - therefore, we have often recommended that they re-run
> ./autogen.sh to pick up local fixes. This would now complicate the
> process for them slightly. So, I believe the right fix may now be to
> dist.sh not autogen.sh - i.e. install the release tarballs of
> apr/apr-util *after* autogen.sh is run instead of beforehand. (BTW,
> neon isn't a required dependency, so I don't view its omission as
> particularly noteworthy.)
>
> I am always willing to discuss any other compromises that you'd like,
> but I'm against removing this 'bug'. -- justin
I don't think that just having code that does something is quite the
same as supporting it - at least, not in a developer-oriented script,
when the code tended to get skipped (if no in-tree apr) or be a benign
waste of time (if in-tree apr from tarball and system autoconf is good)
in most cases. Therefore, it was ignored, and left alone as
circumstances changed, for a long period of time.
There should be no silent breakage: any breakage should result in a
rather obvious error message (absence of configure), with a trivial fix
(run buildconf).
My interpretation of the presence of this code is that it existed to
facilitate the situation in an earlier era of APR development, when APR
was traditionally treated more as an embeddable subtree of code, than an
external library. It is from this I derive the appellation "long obsolete".
I term it a "bug", because it seems unwise, and as recently
demonstrated, potentially error-causing to re-autoconf things
unnecessarily - at least, as a default.
My core miscalculation here, it seems, is assuming that there couldn't
possibly be any developers nesting apr/apr-util working copies in svn
working copies. To me, it makes more sense to manage the build of the
dependencies and Subversion itself separately, to retain control of what
you are building when, permit easier sharing of one apr build among
multiple svn working copies, and to make it easier to do a clean build
of Subversion without rebuilding apr.
I'm not clear what advantages nesting dependency working copies brings,
but apparently they are useful to you.
Would restoring the recursion code within a conditional selected by
'./autogen.sh --recurse' be acceptable?
Max.
Received on Sat Jul 15 23:34:08 2006