Tracker for bugs which fail on unknown arguments with --enable-option-checking=fatal (built into autoconf). You can set this in EXTRA_ECONF in make.conf.
Also, at risk of stating the obvious: please be careful not to just drop invalid arguments and move on. They may well have been renamed or become unconditionally enabled, etc, hence needing more ebuild changes than just dropping the configure arg.
Since bug 828858 was reported for app-emacs/mew, let me quote from the autoconf-2.71 manual, section 15.5: "Source trees often contain multiple packages with a top-level ‘configure’ script that uses the ‘AC_CONFIG_SUBDIRS’ macro (*note Subdirectories::). Because the packages generally support different ‘--with-PACKAGE’ and ‘--enable-FEATURE’ options, the GNU Coding Standards say they must accept unrecognized options without halting. Even a warning message is undesirable here, so ‘AC_CONFIG_SUBDIRS’ automatically disables the warnings." That's exactly what happens for app-emacs/mew, namely a top-level configure script which calls AC_CONFIG_SUBDIRS(bin). The subdir configure script has no need for the --with-elispdir and --with-etcdir options and therefore doesn't recognise them. It all works as intended and is a use case documented in the autoconf manual.
I explained the situation on an upstream bug [0] but quoting it here: >Apologies for the noise both! The bug is invalid and can be closed but it's my >fault. > >Summary: >In Gentoo, we have some automatic detection for build logs where we look for >e.g. 'unrecognized argument: ...' for some reason, this doesn't always work >even when packages lack subconfigure (net-misc/curl seems to be an example of >this!) > >I asked toralf to pass '--enable-option-checking=fatal' (he later changed >it to 'warn') to help find some of those "curl-like: examples" > >The problem is that option also affects subconfigure (where you call configure >for a mini project within your main one), which autoconf says >unknown arguments >are okay for (we don't care about this in gentoo obviously because autoconf >says it's fine): gnu.org/software/autoconf/manual/autoconf-2.69/html_node>/Option-Checking.html > >We need to understand why e.g. net-misc/curl is different: >what is it doing >differently? is it somehow disabling the normal warning? > >(A lot of the bugs toralf filed are legit, >curl-like cases, but some of them >were false positives, like this eggdrop one (because of subconfigure).) > >I'm sorry for the hassle! [0] https://github.com/eggheads/eggdrop/issues/1247#issuecomment-997128010
I explained the situation on an upstream bug [0] but quoting it here: ``` Apologies for the noise both! The bug is invalid and can be closed but it's my fault. Summary: In Gentoo, we have some automatic detection for build logs where we look for e.g. 'unrecognized argument: ...' for some reason, this doesn't always work even when packages lack subconfigure (net-misc/curl seems to be an example of this!) I asked toralf to pass '--enable-option-checking=fatal' (he later changed it to 'warn') to help find some of those "curl-like: examples The problem is that option also affects subconfigure (where you call configure for a mini project within your main one), which autoconf says unknown arguments are okay for (we don't care about this in gentoo obviously because autoconf says it's fine): gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Option-Checking.html We need to understand why e.g. net-misc/curl is different: what is it doing differently? is it somehow disabling the normal warning? (A lot of the bugs toralf filed are legit, curl-like cases, but some of them were false positives, like this eggdrop one (because of subconfigure).) I'm sorry for the hassle! ``` As I discussed with ulm in #gentoo-qa a few weeks ago, what we might really want (if we can't identify what makes e.g. net-misc/curl special) is seeing if autoconf would mind adding a version of this option that was only effective for top-level configure. [0] https://github.com/eggheads/eggdrop/issues/1247#issuecomment-997128010