Hello, On Fri, Jul 01, 2005 at 02:33:57PM +0200, Ralf Wildenhues wrote: > > 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. Of course I don't know. But it's so poorly designed, that I think it's good to deprecate it. > > AC_LANG_COMPILER_C_O([IF-WORKS], [IF-DOESNT]) ... > 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. I think that a cleanly designed test on Autoconf side is a good start for both Automake and Libtool. > - 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. Please note that automake/m4/minuso.m4 mentions plans to introduce something like AC_SUBST([am__CC], ['$(top_srcdir)/compile $(CC)']) Things might get interesting in future versions. > - 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. Again, the questionis whether AC_LANG_COMPILER_C_O would fit for this purpose. > 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. Let's fix it when it strikes. Stepan _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
