Skip site navigation (1) Skip section navigation (2)

Re: Have configure complain about unknown options

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Dave Page <dpage(at)vale-housing(dot)co(dot)uk>,Marko Kreen <markokr(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-patches(at)postgresql(dot)org
Subject: Re: Have configure complain about unknown options
Date: 2006-05-05 13:34:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Fri, May 05, 2006 at 09:13:54AM -0400, Alvaro Herrera wrote:
> > Well, --strict would be tricky, if it's possible. My reading of the
> > autoconf code doesn't indicate a means of doing adding abitrary
> > options. But something like --enable-strict-options would be fairly
> > straight forward. Problem being, if you mistype that option, it'll seem
> > to work even when it isn't :)
> I've been bitten by this in the past as well.  I'd vote for applying the
> patch as-is, no "strict mode" necessary (because, as you say, it's easy
> to get it wrong).

How about the reverse, an option to relax the checking.
--disable-strict-options for example?

> Can the Debian build script be fixed?  Does the RPM spec have the same
> problem?

Looking at the source it may be an artifact of the CDBS build system
used to build the package. It knows that the autotools are in use and
appends it automatically. FWIW, I'd just add a line to the case
statement accepting the enable_maintainer_mode variable since it's
harmless and we're trying to catch typos here, not actual options that
don't apply in our case.

Have a nice day,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> From each according to his ability. To each according to his ability to litigate.

In response to


pgsql-patches by date

Next:From: Hannu KrosingDate: 2006-05-05 13:55:29
Subject: Re: plpython improvements
Previous:From: Alvaro HerreraDate: 2006-05-05 13:13:54
Subject: Re: Have configure complain about unknown options

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group