bug#7434: When an incorrect option is used before --help/--version, automake behaviour is inconsistent with that of other GNU programs.

[Stefano Lattarini]

Severity: wishlist

Currently, automake and aclocal scan their command line looking for
`--help' and `--version' even after an invalid option has been seen;
and in case one of those two options is seen, it takes precedence
even over error reporting about preceding invalid options.

But this is inconsistent with the behaviour of many others GNU/free
programs; for example:

  $ m4 --version --no-such-option; echo \$? = $?
  m4 (GNU M4) 1.4.14
  Copyright (C) 2010 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Written by Rene' Seindal.
  $? = 0

  $ m4 --no-such-option --version; echo \$? = $?
  m4: unrecognized option '--no-such-option'
  Try `m4 --help' for more information.
  $? = 1

The same beheaviour of GNU m4 can be observed with at least GNU sed,
GNU awk, GNU coreutils, GNU bison, flex, gzip, bzip2, xz, GNU libtool,
GNU autoconf, GNU tar, Zsh, and Git.

On the other hand:
  - Bash exit with failure also in the case an invalid option is used
    *after* `--version' or `--help', but I see no reason to copy this
    behaviour, which IMHO is (slighty) suboptimal, and not at all
    widespread.
  - GCC behaves as automake and aclocal currently do, but it has always
    had a peculiar semantic of command-line scanning, for both intrinsic
    and historical reasons; so it's not a good model to follow IMHO.

In conclusion: would you agree with a patch that converts automake and
aclocal to the same cmdline-scanning behaviour of the majority of other
GNU tools?  Such a patch would also have the advantage of *simplifying*
the current code for command line parsing in automake and aclocal.

Regards,
  Stefano