Re: AC_PROG_CC_C_O

[Ralf Wildenhues]

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