Justin Erenkrantz wrote:
> On 7/15/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
>> For what it's worth, we probably want to do this if the deps are svn
>> working copies as opposed to untarred releases...
>
> Agreed. It can check for the presence of srclib/apr/.svn, etc...but
> the change as-is gets a -1. -- justin
Hey, wait a minute, and stop flinging -1s around.
What justification is there for the Subversion buildsystem to be doing
this at all?
It made sense in the days when APR was still hovering on the border
between an included subdirectory of source and a mature library, but
that time has passed.
Nowadays, Subversion offers, as a courtesy, the ability to drive the
build of APR during its own build, for the sake of users who don't
already have it installed. The contract for that is that you place a
suitable APR source tree inside the Subversion source directory.
autogen.sh, however, is a developer tool. If a developer wants to place
an APR working copy inside the Subversion source directory, it is their
responsibility to turn it into a properly buildable piece of source by
running buildconf.
I can not see any self-evident justification why developer parts of the
Subversion build system should be performing actions on APR's build
system, therefore I consider this -1 to be inadequately justified, and
therefore, dispelled.
Yes, this change was a change of the status quo, but as I see it, it was
merely cutting long-inappropriate legacy code. If there is reason to
consider it otherwise, please clarify that reasoning.
Max.
Received on Sat Jul 15 18:33:51 2006