SEO

Currently, configure ignores unknown --enable/disable/with/without
options. Personally I find this behaviour annoying, so here is a patch
that fixes it. Example:

$ ./configure --enable-depends
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
<snip>
checking whether to build with Bonjour support... no
checking whether to build with OpenSSL support... no
*** Unknown feature: enable_depends ***
$

Now, while the error message could do with some help (feedback welcome)
I personally find this to be quite useful.

This patch will detect any argument that isn't declared using one of
the PGAC_ARG macros. This means that if there are any other
--enable/with arguments we accept but don't declare, this will barf on
them too. Do we have any of those? If so, we should document them
somewhere, if necessary creating a PGAC_ARG_HIDDEN so they can pass
this test.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEWdrjIB7bNG8LQkwRAjyxAJ4g0DdFXeA2C0ndjBDNGI ytAI+2hwCeOQqK
VfWjC1IOtfwq+1hoLS6BnJk=
=0XUO
-----END PGP SIGNATURE-----

Martijn van Oosterhout <kleptog@svana.org> writes:
> Currently, configure ignores unknown --enable/disable/with/without
> options.

The autoconf people consider that a feature, not a bug. I'm
disinclined to second-guess the designers of the tool, especially
with a patch like this that mucks with the internals to the extent that
it'll probably break in every future autoconf revision.

Feel free to try to convince them to change it though ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Thu, May 04, 2006 at 12:51:34PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > Currently, configure ignores unknown --enable/disable/with/without
> > options.
>
> The autoconf people consider that a feature, not a bug. I'm
> disinclined to second-guess the designers of the tool, especially
> with a patch like this that mucks with the internals to the extent that
> it'll probably break in every future autoconf revision.

Fair enough. It should work on any version since 2000 since this is the
way you build up strings. Diversions are a feature of m4 not of
autoconf so it's not like they're going away...

> Feel free to try to convince them to change it though ...

Not me, I'll keep it in my local repository then. I'm always
misspelling --enable-depends and this catches it...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD4DBQFEWkwAIB7bNG8LQkwRAkiuAJ0TCW34KKYJFgM9DTrRcw t4LJj/JwCUDDVE
MMmVQU6+05/4+y5Qpez/YQ==
=Le3r
-----END PGP SIGNATURE-----

On 5/4/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > Currently, configure ignores unknown --enable/disable/with/without
> > options.
>
> The autoconf people consider that a feature, not a bug. I'm
> disinclined to second-guess the designers of the tool, especially
> with a patch like this that mucks with the internals to the extent that
> it'll probably break in every future autoconf revision.
>
> Feel free to try to convince them to change it though ...

AFAIK that 'feature' is there to support configuring a 'tree'
of projects (like gcc), where subprojects have their own configure
scripts with different options. That way you can give all options
to top-level configure script which passes them to other scripts and
each picks only whats needed. In such setting all scripts need to
ignore unknown options.

As PostgreSQL tree is not set up that way, I think for clarity sake
it would be better to give explicit errors for unknown options.

--
marko

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Fri, May 05, 2006 at 02:22:25PM +0300, Marko Kreen wrote:
> AFAIK that 'feature' is there to support configuring a 'tree'
> of projects (like gcc), where subprojects have their own configure
> scripts with different options. That way you can give all options
> to top-level configure script which passes them to other scripts and
> each picks only whats needed. In such setting all scripts need to
> ignore unknown options.

I was wondering about that. I think it's also because there are
possibly a number of tools working together (autoheader/automake/etc)
and autoconf is not in the position to know all possible options.
You're not required to declare all the options you understand in
configure.in because they may be used elsewhere.

> As PostgreSQL tree is not set up that way, I think for clarity sake
> it would be better to give explicit errors for unknown options.

Someone in the past has gone to some effort to create a bunch of macros
for postgres that declares all the options our configure script
understands and simultaneously create help for them (this is also why
the patch is so small, the hard work of identifying the options was
done long ago). So we are in a position to know what is allowed and
what isn't.

One thing I've noticed so far is that the Debian package scripts use
--enable-maintainer-mode. No idea why, that affects automake, which we
don't use. It is however an excellent example of why complaining about
unknown options can't be done in the general case.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEWzmCIB7bNG8LQkwRAqrmAJ9rAf5LrzGrRsD779uCTO Bh5oiZ/ACeM1p7
alafQ7FFlhclfypHmlu12g4=
=9/L6
-----END PGP SIGNATURE-----