the compilation gnome-extra/gnome-documents-3.8.1 of always leads to a QA notice: >>> Messages generated by process 25024 on 2013-04-26 16:49:00 CEST for package gnome-extra/gnome-documents-3.8.1: QA: install QA Notice: Unrecognized configure options: --disable-schemas-compile --disable-schemas-compile This is caused by the cheap grep conditions found in /usr/portage/eclass/gnome2.eclass, which succeeded: # Pass --disable-schemas-install when possible if grep -q "disable-schemas-install" ${ECONF_SOURCE:-.}/configure; then G2CONF="--disable-schemas-install ${G2CONF}" fi # Pass --disable-schemas-compile when possible if grep -q "disable-schemas-compile" ${ECONF_SOURCE:-.}/configure; then G2CONF="--disable-schemas-compile ${G2CONF}" fi GLIB_GSETTINGS cl in configure.ac is responsible for the generation of this options, which is present. This happens because configure file may contain "--disable-schemas-compile" in the option message string despite the fact that this options are not present at all!!! in that case, one may have to rerun aclocal to pull together macros from various sources, which is not what everybody wants, so the other solution would be to grep additionally for something else, like "enable_schemas_compile" Reproducible: Always
No, this is caused because it runs a second configure that doesn't honor the option (while main one does): configure: Configuring sources in egg-list-box configure: running /bin/sh ./configure '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--disable-silent-rules' '--disable-dependency-tracking' '--disable-schemas-compile' '--disable-maintainer-mode' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-O2 -pipe -march=native' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu' 'PKG_CONFIG_PATH=/usr/lib64/pkgconfig' 'CXXFLAGS=-O2 -pipe -march=native' --cache-file=/dev/null --srcdir=. configure: WARNING: unrecognized options: --disable-schemas-compile This is a common problem that affects to a lot of other packages running multiple configure scripts I would use QA_CONFIGURE_OPTIONS options to prevent the warning in ebuild :/
Like done in: https://bugs.gentoo.org/show_bug.cgi?id=401733 https://bugs.gentoo.org/show_bug.cgi?id=446662 Maybe could be set via eclass
I do not quite understand what do you mean by two configure scripts? even if there are two the doubled appearance of the same QA message can be explained)) I looked for configure script after extracting the tarball, opened it and grepped for "disable-schemas-compile". The problem was that I have found the match in the option string message, but the option itself was not present, so the condition in the eclass failed!
$ ./configure --disable-schemas-compile checking whether make supports nested variables... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu [...] -> The option is recognized here configure: creating ./config.status config.status: creating Makefile config.status: creating egg-list-box-uninstalled.pc config.status: creating egg-flow-box-uninstalled.pc config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands configure: WARNING: unrecognized options: --disable-schemas-compile configure: Done configuring in egg-list-box checking for DOCUMENTS... yes checking for MINER... yes [...] -> But not here, that is when egg-list-box is configured
Imho, it is not the job of the eclass to account for sub-configure errors. You would have them anyway if you set the option in the ebuild directly and it is just an error of the maintainer to not set QA_CONFIGURE_OPTIONS when testing the ebuild.
Well, the idea of doing it at eclass level is to ensure that people won't be warned for this switchers as they are passed by the eclass when the main configure has them :/
But this is handling a corner case that the maintainer of the package should have seen. It is a maintenance error and I do not agree to hide that. Imho the problem is larger than that, portage should automatically disable this warning for package that have a subconfigure but I guess it's not easy to do for portage.
(In reply to Gilles Dartiguelongue from comment #7) > But this is handling a corner case that the maintainer of the package should > have seen. It is a maintenance error and I do not agree to hide that. > > Imho the problem is larger than that, portage should automatically disable > this warning for package that have a subconfigure but I guess it's not easy > to do for portage. Closing then
