Benoit Sigoure <tsuna@xxxxxxxxxxxxx> writes: > Alright I understand, however I still think that Steven's idea is good > and I've > also been bitten by wrong configure options being silently ignored, so > would it > make sense to add a macro such as AC_ENABLE_STRICT_OPTION_CHECKING or whatever > that would enable the behavior described by Steven (although it slightly > conflicts with the GNU CS)? I'd definitely use such a macro everywhere I can. > As an autotools user, I am forced to agree that this is a significant problem. So much so, that for every option the user can set, I put a line in the output, recording the choice. If there is a problem, that's the first thing I check, to ensure that I typed in the options I wanted. The output looks like this: checking whether only the C library is desired... no checking whether examples should be built... yes checking whether F77 API is desired... yes checking whether F90 API is desired... yes checking whether C API is desired... yes checking whether CXX API is desired... yes checking whether v2 netCDF API should be built... yes and on and on... Similarly, if a user has a problem, this is the first place I check. And yet, it should be easy for configure to at least warn about any arguments that have no known meaning. How about a macro which, when invoked in the configure.ac, would turn on such warnings for that configure script. However, this does make life harder on those who are trying to assemble collections of releases, and as this is something I'm about to try myself, I might have a different viewpoint in six months... Thanks, Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
