On 22.02.2013 20:00, Greg Stein wrote:
> On Fri, Feb 22, 2013 at 12:41 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>> On 22.02.2013 18:35, Greg Stein wrote:
>>>
>>> On Feb 22, 2013 10:51 AM, "Ben Reser" <ben_at_reser.org
>>> <mailto:ben_at_reser.org>> wrote:
>>>> On Fri, Feb 22, 2013 at 7:04 AM, Philip Martin
>>>> <philip.martin_at_wandisco.com <mailto:philip.martin_at_wandisco.com>> wrote:
>>>>> Did you mean an in-tree build rather than a static build? I don't
>>> think
>>>>> we support building serf in-tree.
>>>> Indeed we do not support in-tree serf builds. Nor is it something
>>>> that is likely to be easy to use, since serf is now using SCons for
>>>> their build system.
>>>>
>>>> We should probably add a note before 1.8 release explaining this since
>>>> you can't simply ./get_deps.sh to cover this dependency now like you
>>>> could with neon.
>>> I'd prefer we remove all in-tree builds, except for the private
>>> copy/build of sqlite. Building that way was a workaround for when our
>>> dependencies where "new on the scene" and were not regularly available
>>> as their own packages/install.
>>>
>> But they're not, and a case in point is the as-yet-unreleased Serf 1.2,
> Unreleased? Dunno what you're talking about.
>
> ;-)
Heh.
>> which 1.8 will depend on, and which isn't likely to get into any major
>> releases within 6 months of the Subversion (or Serf) release. (And
>> neither is SVN, fwiw).
> I don't think the answer is "build them in our tree". That just serves
> to monkey up our build, and make it overly complicated. The correct
> response is "build and install $PACKAGE on your system. *then* build
> Subversion."
I guess I'm mixing apples and oranges. It's OK to disable all in-tree
automagic recursive builds, but let's keep get-deps.sh up-to-date was
what I really meant.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-02-23 01:37:35 CET