You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2013/02/22 13:32:19 UTC
OOD configure options
The configure option --with-ssl seems to be a remnant of our neon
support, it allowed --with-ssl to be passed to an in-tree neon build.
I think it can be removed.
The --with-gssapi option seems to be related to serf but I don't
understand it. It causes the gssapi libraries to be added to the link
but why is that necessary? Doesn't serf itself add the libraries it
needs? This config option also defines SVN_RA_SERF_HAVE_GSSAPI which
seems to be unused. Can we remove --with-gssapi as well?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
RE: OOD configure options
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: vrijdag 22 februari 2013 13:32
> To: dev@subversion.apache.org
> Subject: OOD configure options
>
> The configure option --with-ssl seems to be a remnant of our neon
> support, it allowed --with-ssl to be passed to an in-tree neon build.
> I think it can be removed.
>
> The --with-gssapi option seems to be related to serf but I don't
> understand it. It causes the gssapi libraries to be added to the link
> but why is that necessary? Doesn't serf itself add the libraries it
> needs? This config option also defines SVN_RA_SERF_HAVE_GSSAPI which
> seems to be unused. Can we remove --with-gssapi as well?
The gss (and other authentication) support was moved from libsvn_ra_serf to
serf itself over the last few years. So I think we can remove these flags
from our build.
Bert
Re: OOD configure options
Posted by Ben Reser <be...@reser.org>.
On Sat, Feb 23, 2013 at 6:24 PM, Greg Stein <gs...@gmail.com> wrote:
> Shouldn't all the instructions be "build it yourself", as we seem agreed to
> rip out in-tree builds of dependent packages?
If it was going to stay `./configure; make; make install` for a long
time then I'd probably document it that way. But in this case I guess
it's best to just say to build it per the instructions provided.
Re: OOD configure options
Posted by Greg Stein <gs...@gmail.com>.
On Feb 23, 2013 7:11 PM, "Ben Reser" <be...@reser.org> wrote:
>
> On Fri, Feb 22, 2013 at 4:37 PM, Branko Čibej <br...@wandisco.com> wrote:
> > 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.
>
> Yup get_deps.sh needs to stay. The instructions just need to be
> updated to say you have to run the build yourself. I notice that serf
> 1.2 has a configure/make setup. Is there a known time frame for when
> serf is going to switch to SCons in released source packaging? The
> answer to that question would likely impact how the instructions
> should be written.
Likely for 1.3, whenever that is. Definitely for 2.0, whenever that is. Not
very helpful, but there ya go :-)
Shouldn't all the instructions be "build it yourself", as we seem agreed to
rip out in-tree builds of dependent packages?
Cheers,
-g
Re: OOD configure options
Posted by Ben Reser <be...@reser.org>.
On Fri, Feb 22, 2013 at 4:37 PM, Branko Čibej <br...@wandisco.com> wrote:
> 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.
Yup get_deps.sh needs to stay. The instructions just need to be
updated to say you have to run the build yourself. I notice that serf
1.2 has a configure/make setup. Is there a known time frame for when
serf is going to switch to SCons in released source packaging? The
answer to that question would likely impact how the instructions
should be written.
Re: OOD configure options
Posted by Branko Čibej <br...@wandisco.com>.
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" <ben@reser.org
>>> <ma...@reser.org>> wrote:
>>>> On Fri, Feb 22, 2013 at 7:04 AM, Philip Martin
>>>> <philip.martin@wandisco.com <ma...@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
Re: OOD configure options
Posted by Greg Stein <gs...@gmail.com>.
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" <ben@reser.org
>> <ma...@reser.org>> wrote:
>> >
>> > On Fri, Feb 22, 2013 at 7:04 AM, Philip Martin
>> > <philip.martin@wandisco.com <ma...@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.
;-)
> 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."
Cheers,
-g
Re: OOD configure options
Posted by Branko Čibej <br...@wandisco.com>.
On 22.02.2013 18:35, Greg Stein wrote:
>
>
> On Feb 22, 2013 10:51 AM, "Ben Reser" <ben@reser.org
> <ma...@reser.org>> wrote:
> >
> > On Fri, Feb 22, 2013 at 7:04 AM, Philip Martin
> > <philip.martin@wandisco.com <ma...@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,
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).
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: OOD configure options
Posted by Greg Stein <gs...@gmail.com>.
On Feb 22, 2013 10:51 AM, "Ben Reser" <be...@reser.org> wrote:
>
> On Fri, Feb 22, 2013 at 7:04 AM, Philip Martin
> <ph...@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.
Cheers,
-g
Re: OOD configure options
Posted by Ben Reser <be...@reser.org>.
On Fri, Feb 22, 2013 at 7:04 AM, Philip Martin
<ph...@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.
Re: OOD configure options
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 22.02.2013 13:32, Philip Martin wrote:
>>> The configure option --with-ssl seems to be a remnant of our neon
>>> support, it allowed --with-ssl to be passed to an in-tree neon build.
>>> I think it can be removed.
>>>
>>> The --with-gssapi option seems to be related to serf but I don't
>>> understand it. It causes the gssapi libraries to be added to the link
>>> but why is that necessary? Doesn't serf itself add the libraries it
>>> needs? This config option also defines SVN_RA_SERF_HAVE_GSSAPI which
>>> seems to be unused. Can we remove --with-gssapi as well?
>>
>> Not for builds that link serf statically.
>
> Why not? Isn't serf supposed to tell us which libraries it needs? Why
> is gssapi different from any other library?
Did you mean an in-tree build rather than a static build? I don't think
we support building serf in-tree.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: OOD configure options
Posted by Branko Čibej <br...@wandisco.com>.
On 22.02.2013 15:34, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 22.02.2013 13:32, Philip Martin wrote:
>>> The configure option --with-ssl seems to be a remnant of our neon
>>> support, it allowed --with-ssl to be passed to an in-tree neon build.
>>> I think it can be removed.
>>>
>>> The --with-gssapi option seems to be related to serf but I don't
>>> understand it. It causes the gssapi libraries to be added to the link
>>> but why is that necessary? Doesn't serf itself add the libraries it
>>> needs? This config option also defines SVN_RA_SERF_HAVE_GSSAPI which
>>> seems to be unused. Can we remove --with-gssapi as well?
>> Not for builds that link serf statically.
> Why not? Isn't serf supposed to tell us which libraries it needs? Why
> is gssapi different from any other library?
Ah, I misunderstood this to mean "remove option implies don't link
library." Indeed, Serf's pkg-config should DTRT.
Sorry for the confusion.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: OOD configure options
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> On 22.02.2013 13:32, Philip Martin wrote:
>> The configure option --with-ssl seems to be a remnant of our neon
>> support, it allowed --with-ssl to be passed to an in-tree neon build.
>> I think it can be removed.
>>
>> The --with-gssapi option seems to be related to serf but I don't
>> understand it. It causes the gssapi libraries to be added to the link
>> but why is that necessary? Doesn't serf itself add the libraries it
>> needs? This config option also defines SVN_RA_SERF_HAVE_GSSAPI which
>> seems to be unused. Can we remove --with-gssapi as well?
>
> Not for builds that link serf statically.
Why not? Isn't serf supposed to tell us which libraries it needs? Why
is gssapi different from any other library?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: OOD configure options
Posted by Branko Čibej <br...@wandisco.com>.
On 22.02.2013 13:32, Philip Martin wrote:
> The configure option --with-ssl seems to be a remnant of our neon
> support, it allowed --with-ssl to be passed to an in-tree neon build.
> I think it can be removed.
>
> The --with-gssapi option seems to be related to serf but I don't
> understand it. It causes the gssapi libraries to be added to the link
> but why is that necessary? Doesn't serf itself add the libraries it
> needs? This config option also defines SVN_RA_SERF_HAVE_GSSAPI which
> seems to be unused. Can we remove --with-gssapi as well?
Not for builds that link serf statically.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com