Hi Stepan, * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST: > > The macro has two uses: > 1) in GNU make's configure.in > 2) in Automake's AM_PROG_CC_C_O How do you know nobody else uses it? It's published. > If yes, shouldn't we introduce a generalized macro, for example > > AC_LANG_COMPILER_C_O([IF-WORKS], [IF-DOESNT]) > > which would test the compiler of the current language? It would be great if, whatever solution turns out to be good for Autoconf and Automake, could also be aligned with Libtool in a sane way. Libtool currently has its own half-working macro for this. Combining is not as simple as it looks like: - if Automake and AM_PROG_CC_C_O are used, Libtool should be able to rely on $CC (which might be `compile ...') to work fine. Not using `compile' in this case would be an optimization (one shell script less to execute), though, albeit one where I don't know how to achieve it without Automake help. - otherwise, Libtool generally may need to do locking itself. The corresponding test should be aligned to Autoconf's, I guess, at least in the long run. Thus, it would be good if Autoconf/Automake provided a macro to test this, without also imposing `compile' in the failure case. One thing I can't remember (and have not searched in the archives yet) is whether some Intel compiler version does not understand `-c -o sub/out.o' (as opposed to `-c -o out.o') but exits with zero nonetheless, only issuing a warning. I do believe some compilers fail on subdir output only, though, gathering from the Libtool macro. Might be FUD, I really don't remember. I know all of this is little help for your task. ;) Regards, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
