On 22.02.2013 20:00, Greg Stein wrote: > On Fri, Feb 22, 2013 at 12:41 PM, Branko Čibej <br...@wandisco.com> wrote: >> On 22.02.2013 18:35, Greg Stein wrote: >>> >>> On Feb 22, 2013 10:51 AM, "Ben Reser" <b...@reser.org >>> <mailto:b...@reser.org>> wrote: >>>> On Fri, Feb 22, 2013 at 7:04 AM, Philip Martin >>>> <philip.mar...@wandisco.com <mailto:philip.mar...@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
