ArchiveOrangemail archive

users.subversion.apache.org


(List home) (Recent threads) (3 other Subversion lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line.
  • Moderate traffic list: up to 30 messages per day
  • This list contains about 16,932 messages, beginning Feb 2010
  • 22 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

Issue: Top-level --with-expat option does not accept apr-util's "builtin" argument

Ad
Daniel Richard G. 1340151056Wed, 20 Jun 2012 00:10:56 +0000 (UTC)
The apr-util package accepts an option --with-expat, described in the
configure script help output as

    --with-expat=DIR        specify Expat location, or 'builtin'

I want to use 'builtin'. Knowing that the options I give to Subversion's
top-level configure script are passed down to the sub-projects, I
specify --with-expat=builtin to the top-level script.

Uh oh, I get this:

    checking for Expat... no
    configure: error: Invalid syntax of argument of --with-expat option

The top-level script also takes a --with-expat option, but it is
described a little differently:

    --with-expat=INCLUDES:LIB_SEARCH_DIRS:LIBS
                            Specify location of Expat

The three-part argument syntax is enforced by the script, which is why
the 'builtin' argument didn't work.

I've attached a proposed patch against SVN that allows the top-level
script to accept the 'builtin' value, and otherwise behave as though the
--with-expat option had not been specified at all.

This is only a partial workaround, however, because if I wanted to
specify an external Expat location to apr-util, there would still be no
way to do so. Either the syntax of these two options needs to be
harmonized, or Subversion should rename its option to something not
already used by a sub-project.


--Daniel

(Please Cc: me on any replies, as I am not subscribed to this list.)
Stefan Sperling 1340186791Wed, 20 Jun 2012 10:06:31 +0000 (UTC)
On Tue, Jun 19, 2012 at 02:10:02PM -0400, Daniel Richard G. wrote:
> Index: configure.ac
> ===================================================================
> --- configure.ac	(revision 1351789)
> +++ configure.ac	(working copy)
> @@ -373,6 +373,9 @@
>                   [svn_lib_expat="$withval"],
>                   [svn_lib_expat="::expat"])
>  
> +# apr-util accepts "builtin" as an argument to this option
> +test "_$svn_lib_expat" = "_builtin" && svn_lib_expat="::expat"
> +Looks like this will make the script error out without an error message.
That might confuse people. Can you please add an error message?

I'd also prefer your test to happen after this message is printed:>  AC_MSG_CHECKING([for Expat])

>  if test -n "`echo "$svn_lib_expat" | $EGREP ":.*:"`"; then
>    SVN_XML_INCLUDES=""
Daniel Richard G. 1340209843Wed, 20 Jun 2012 16:30:43 +0000 (UTC)
Hi Stefan,On Wed, 2012 Jun 20 12:05+0200, Stefan Sperling wrote:
> >
> > +# apr-util accepts "builtin" as an argument to this option
> > +test "_$svn_lib_expat" = "_builtin" && svn_lib_expat="::expat"
>
> Looks like this will make the script error out without an error
> message. That might confuse people. Can you please add an error
> message?Do you mean, this causes the script to error out in "set -e" mode? If
that's it, the line could be re-written as

    test "_$svn_lib_expat" != "_builtin" || svn_lib_expat="::expat"

This isn't meant to raise an error at all; the aim is to fool the
top-level script into thinking the user didn't specify --with-expat=* in
this one specific case.


--Daniel
Stefan Sperling 1340214419Wed, 20 Jun 2012 17:46:59 +0000 (UTC)
On Wed, Jun 20, 2012 at 12:30:16PM -0400, Daniel Richard G. wrote:
> This isn't meant to raise an error at all; the aim is to fool the
> top-level script into thinking the user didn't specify --with-expat=* in
> this one specific case.Ah, I see. I misunderstood the code you've written.
Committed, with a more elaborate comment, in r1352231. Thanks!
Home | About | Privacy