Re: Have configure complain about unknown options

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Have configure complain about unknown options
Date: 2006-05-11 23:15:33
Message-ID: 20060511231532.GA4268@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Tue, May 09, 2006 at 02:00:34PM +0200, Peter Eisentraut wrote:
> Am Dienstag, 9. Mai 2006 10:55 schrieb Martijn van Oosterhout:
> > Can you explain why? Unknown options don't do anything, so having users
> > remove them seems like a good move.
>
> Build system frameworks assume that they can pass any option and that unknown
> options will be ignored. This grew out of the old Cygnus GNU megatree but as
> you saw it is also used by package building frameworks like CDBS. In fact,
> if we one day separate the PLs into separate source tarballs, I'd like to set
> up a similar megatree system so building everything becomes easier.
>
> I don't object to having a strict mode or printing warnings or printing a
> summary at the end, but we are not in a position to redefine build system
> practice.

Then it seems like the best way to go would be to provide
--disable-strict-mode. I dislike the idea of printing a summary, because
it's easy to miss problems there, and it's also very counter-intuitive.
Until now I'd always assumed that configure would always complain about
invalid arguments because I've seen it happen before; I didn't think
you'd actually have to write code to make it do that (talk about a
brain-dead tool...)

In any case, I think the real use case here is catching errors from
general users who are installing from source, which disqualifies
--enable-strict as well as setting a shell alias.

Hopefully no one finds any need to use --disable-strict and it can just
be dropped down the road...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Jim C. Nasby 2006-05-11 23:37:03 Re: [PATCH] Improve EXPLAIN ANALYZE overhead by sampling
Previous Message spaminos-sql 2006-05-11 22:35:47 Querying libpq compile time options