Re: AM_PROG_CC_C_O assumption

[Ralf Wildenhues]

Hi Alexandre,

* Alexandre Duret-Lutz wrote on Fri, Mar 10, 2006 at 11:51:12AM CET:
> >>> "RW" == Ralf Wildenhues <address@hidden> writes:
> 
>  RW> CVS Automake assumes that, as soon as per-target compile flags are used,
>  RW> AM_PROG_CC_C_O is necessary.
> 
> Not exactly : it assumes that AM_PROG_CC_C_O is necessary as
> soon as -c and -o are used.  Automake has always used -c -o for
> per-target compile flags as well as for subdir-objects, however
> previous versions of Automake forgot to require AM_PROG_CC_C_O
> in the former case (but did in the letter).

Ah, yes.  Thanks for the correction.

>  RW> However, in practice there are many Makefile.am's out there that use
>  RW> target_CFLAGS and such, and will definitely never have name conflicts
> 
> This means we don't have to rename the objects file in all
> cases.  I agree, but it's seem too hard to tell.  Since
> currently Automake always uses -c -o in this case, the presence
> or absence of conflicts isn't a justification against or for
> AM_PROG_CC_C_O.

Agreed, too.

>  RW> and/or never possibly be used by a losing compiler.  
> 
> Definitely.

Yes, this is the real reason against it.

>  RW> And as such I think it is too harsh to have Automake fail
>  RW> hard in this case; giving a warning would be sufficient
>  RW> IMVHO.
> 
> OK, let's turn in into a portability warning.  And since
> portability warnings have been waiting to be turned on for three
> years now, let's do that too.  I'm installing the following two
> patches.

Thanks!  Note there's a typo, see below.

>  RW> For example, the modular Xorg tree would need hundreds of changes to get
>  RW> working, most of them actually in Makefile.am's that build only one
>  RW> object.

> I'm not sure why the changes need to be in Makefile.ams.  Why not add
> AM_PROG_CC_C_O to configure.ac?

Oh, they don't need to be.  But Xorg split the source into very many
complete packages, each only building one small program, so those
changes would translate to hundreds of configure.ac that needed changed
in turn.  Given the option of either adding AM_PROG_CC_C_O or removing
the need for it and another script in the tarball, I go for the latter.
:-)

Cheers,
Ralf

| @@ -5242,7 +5242,8 @@
| 
|           # libtool is always able to put the object at the proper place,
|           # so we do not have to require AM_PROG_CC_C_O when building .lo 
files.
| -         err_var ($var, "compiling `$base.c' in subdir requires "
| +         msg_var ('portabiliy', $var,

portability.

| +                  "compiling `$base.c' in subdir requires "
|                    . "`AM_PROG_CC_C_O' in `$configure_ac'",
|                    uniq_scope => US_GLOBAL,
|                    uniq_part => 'AM_PROG_CC_C_O subdir')