Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <72b68e9be40146aeabb649f7d2fd8ce7@SP39.realvnc.ltd>
References: <72b68e9be40146aeabb649f7d2fd8ce7@SP39.realvnc.ltd>
Date: Fri, 15 May 2015 19:49:37 +0200
Message-ID: 
 <CABh03acihew1nH9Rz-2Cr1TLa50GgXmQDzhR9twKcCTLgSV6BA@mail.gmail.com>
Subject: Re: Subversion configure script broken for serf if sysroot path
 contains "-D"
From: =?UTF-8?Q?Branko_=C4=8Cibej?= <brane@wandisco.com>
To: Bruce Bye <bruce.bye@realvnc.com>
Cc: Subversion Development <dev@subversion.apache.org>
Content-Type: multipart/alternative; boundary=bcaec51ddef1bd9522051622773f

--bcaec51ddef1bd9522051622773f
Content-Type: text/plain; charset=UTF-8

>>
>> There's really no completely safe way to rewrite that regular
expression. But I think you can avoid even invoking it by passing
--with-serf=/path/to/serf/prefix to configure; if the Serf path is
provided, we won't invoke pkg-config.
>
> Of course - a completely safe fix would have to do something rather
different from a simple regex to ensure it wasn't catching something it
didn't intend to, and may not be worth the effort. I would think that
adding a space in the regex before the hyphen might be sufficient, but I
don't know if you need to worry about a -D option at the very start of the
cflags string.  Adding the space into the regex is how I'm working around
the issue for now.

Right. Adding the space, and a separate check for the start of the string,
would help.

>
> But then, since what the code is actually trying to get is the include
path and not the full cflags, perhaps it could instead request
--variable=includedir from pkg-config, and not need to munge the string at
all.

Do you mind trying that? I'm sure a patch that does away with the regex
filter entirely would be welcome.

-- Brane

--bcaec51ddef1bd9522051622773f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
&gt;&gt;<br>
&gt;&gt; There&#39;s really no completely safe way to rewrite that regular =
expression. But I think you can avoid even invoking it by passing --with-se=
rf=3D/path/to/serf/prefix to configure; if the Serf path is provided, we wo=
n&#39;t invoke pkg-config.<br>
&gt;<br>
&gt; Of course - a completely safe fix would have to do something rather di=
fferent from a simple regex to ensure it wasn&#39;t catching something it d=
idn&#39;t intend to, and may not be worth the effort. I would think that ad=
ding a space in the regex before the hyphen might be sufficient, but I don&=
#39;t know if you need to worry about a -D option at the very start of the =
cflags string.=C2=A0 Adding the space into the regex is how I&#39;m working=
 around the issue for now.</p>
<p dir=3D"ltr">Right. Adding the space, and a separate check for the start =
of the string, would help.<br></p>
<p dir=3D"ltr">&gt;<br>
&gt; But then, since what the code is actually trying to get is the include=
 path and not the full cflags, perhaps it could instead request --variable=
=3Dincludedir from pkg-config, and not need to munge the string at all.</p>
<p dir=3D"ltr">Do you mind trying that? I&#39;m sure a patch that does away=
 with the regex filter entirely would be welcome.</p>
<p dir=3D"ltr">-- Brane</p>

--bcaec51ddef1bd9522051622773f--