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
[email protected]
http://lists.gnu.org/mailman/listinfo/autoconf
