Re: AC_PROG_CC_C_O

[Stepan Kasal]

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