GNU bug report logs - #13378
Make the 'subdir-objects' setup the default, and only available one

Previous Next

To reply to this bug, email your comments to 13378 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: [IMPORTANT] Make the 'subdir-objects' setup the default, and only
	available one
Date: Mon, 07 Jan 2013 21:08:33 +0100

Severity: wishlist

Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07,
"[ng] subdir-objects: enable unconditionally".

The fact that Automake-generated Makefiles place compiled object files in
he current directory by default, also when the corresponding source file
is in a subdirectory, is basically an historical accident, due to the fact
that the 'subdir-objects' option had only been introduced in April 1999,
starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never
made the default (likely to avoid backwards-compatibility issues).

Since I believe the behaviour enabled by the 'subdir-objects' is the most
useful one, and in fact the *only* natural one, I'd like to make it the
the only one available, simplifying the Automake implementation and APIs
a little in the process.

Alas, since this also means changing the default behaviour of Automake
('subdir-objects' is not enabled by default, sadly), this means the
transition path will be less smooth than I'd like.  Here it is a sketch
for it:

  Automake 1.13.2
  ---------------

  Give a warning in the category 'unsupported' if the 'subdir-objects'
  option is not specified.  This should give the users enough forewarning
  about the planned change, and give them time to update their packages
  to the new semantic.

  Automake 1.14
  -------------

  Flip the 'subdir-object' option on by default.  At the same time,
  drop support for the "old" behaviour of having object files derived
  from sources in a subdirectory being placed in the current directory
  rather than in that same subdirectory.

  Still keep the 'subdir-object' option supported (as a simple no-op
  now), to save useless churn in our user's build systems.

Thoughts, opinions?

Regards,
  Stefano

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 07:55:02 +1000

On 1/8/13 6:08 AM, Stefano Lattarini wrote:
> Severity: wishlist
>
> Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07,
> "[ng] subdir-objects: enable unconditionally".
>
> The fact that Automake-generated Makefiles place compiled object files in
> he current directory by default, also when the corresponding source file
> is in a subdirectory, is basically an historical accident, due to the fact
> that the 'subdir-objects' option had only been introduced in April 1999,
> starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never
> made the default (likely to avoid backwards-compatibility issues).
If the maintainer didn't wanna break compatibility backwards back then, 
why is it a better idea to break it today?
> Since I believe the behaviour enabled by the 'subdir-objects' is the most
> useful one, and in fact the *only* natural one, I'd like to make it the
> the only one available, simplifying the Automake implementation and APIs
> a little in the process.
>
> Alas, since this also means changing the default behaviour of Automake
> ('subdir-objects' is not enabled by default, sadly), this means the
> transition path will be less smooth than I'd like.  Here it is a sketch
> for it:
>
>    Automake 1.13.2
>    ---------------
>
>    Give a warning in the category 'unsupported' if the 'subdir-objects'
>    option is not specified.

I assume user will get no warning when irrelevant, i.e., if all source 
files sit in current directory there is no need to give this warning.

>   This should give the users enough forewarning
>    about the planned change, and give them time to update their packages
>    to the new semantic.
You assume users install every version of Automake you release. In my 
understanding going from 1.13 to 1.14 is similar to go from Autoconf 
2.68 to 2.69.

Cheers,
Peter

-- 
Peter Johansson

Message #11 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Mon, 07 Jan 2013 23:18:33 +0100

Hi Peter, thanks for the feedback.

On 01/07/2013 10:55 PM, Peter Johansson wrote:
> On 1/8/13 6:08 AM, Stefano Lattarini wrote:
>> Severity: wishlist
>>
>> Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07,
>> "[ng] subdir-objects: enable unconditionally".
>>
>> The fact that Automake-generated Makefiles place compiled object files in
>> he current directory by default, also when the corresponding source file
>> is in a subdirectory, is basically an historical accident, due to the fact
>> that the 'subdir-objects' option had only been introduced in April 1999,
>> starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never
>> made the default (likely to avoid backwards-compatibility issues).
>
> If the maintainer didn't wanna break compatibility backwards back then,
> why is it a better idea to break it today?
>
Because the 'subdir-objects' option has since been extensively tested
on field, and shown to be reliable and offer better semantics.  Also,
more importantly, in my experience the great majority of projects that
have source files in a subdirectory not in SUBDIRS already use the
'subdir-objects' option anyway, so they wouldn't experience any kind of
compatibility issue.

>> Since I believe the behaviour enabled by the 'subdir-objects' is the most
>> useful one, and in fact the *only* natural one, I'd like to make it the
>> the only one available, simplifying the Automake implementation and APIs
>> a little in the process.
>>
>> Alas, since this also means changing the default behaviour of Automake
>> ('subdir-objects' is not enabled by default, sadly), this means the
>> transition path will be less smooth than I'd like.  Here it is a sketch
>> for it:
>>
>>    Automake 1.13.2
>>    ---------------
>>
>>    Give a warning in the category 'unsupported' if the 'subdir-objects'
>>    option is not specified.
> 
> I assume user will get no warning when irrelevant, i.e., if all source files
> sit in current directory there is no need to give this warning.
>
Indeed, good point.  The same way we will not require AM_PROG_CC_C_O
if all source files sit in current directory.

>>   This should give the users enough forewarning
>>    about the planned change, and give them time to update their packages
>>    to the new semantic.
> You assume users install every version of Automake you release.
>
This "smoother transition" is more intended to be of help for distro packagers
actually.  They tend to test with more Automake versions, and will likely make
this kind of warnings percolate to the upstream maintainers.  Not perfect, but
the best we can do, reasonably.

> In my understanding going from 1.13 to 1.14 is similar to go from Autoconf
> 2.68 to 2.69.
>
Actually no, the change tend to be much more extensive (as they've been
between 1.12 and 1.13, not always smoothly or pleasantly).  Maybe, to make
this clear, we should name release a 2.0 version instead of a 1.14?

Thanks,
  Stefano

Message #14 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 08:58:12 +1000

Hi Stefano,

On 01/08/2013 08:18 AM, Stefano Lattarini wrote:
> Actually no, the change tend to be much more extensive (as they've been
> between 1.12 and 1.13, not always smoothly or pleasantly).  Maybe, to make
> this clear, we should name release a 2.0 version instead of a 1.14?
No need, IMHO. Perhaps a brief document communicating what could be 
expected between versions such as "a Makefile.am that works with 
Automake 1.14 will also compile with Automake 1.14.1; new warning might 
get introduced though...". But OTOH there are perhaps more important 
things to do than writing policies.

Cheers,
Peter

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Breitenlohner <peb <at> mppmu.mpg.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 8 Jan 2013 10:57:09 +0100 (CET)

On Mon, 7 Jan 2013, Stefano Lattarini wrote:

> Alas, since this also means changing the default behaviour of Automake
> ('subdir-objects' is not enabled by default, sadly), this means the
> transition path will be less smooth than I'd like.  Here it is a sketch
> for it:
>
>  Automake 1.13.2
>  ---------------
>
>  Give a warning in the category 'unsupported' if the 'subdir-objects'
>  option is not specified.  This should give the users enough forewarning
>  about the planned change, and give them time to update their packages
>  to the new semantic.

Hi Stefano,

this warning (given when there are C - or other? - sources in subdirs)
should also mention the need to use AM_PROG_CC_C_O.

Regards
Peter Breitenlohner <peb <at> mppmu.mpg.de>

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Breitenlohner <peb <at> mppmu.mpg.de>
Cc: bug-automake <at> gnu.org, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 11:35:58 +0100

On 01/08/2013 10:57 AM, Peter Breitenlohner wrote:
> On Mon, 7 Jan 2013, Stefano Lattarini wrote:
> 
>> Alas, since this also means changing the default behaviour of Automake
>> ('subdir-objects' is not enabled by default, sadly), this means the
>> transition path will be less smooth than I'd like.  Here it is a sketch
>> for it:
>>
>>  Automake 1.13.2
>>  ---------------
>>
>>  Give a warning in the category 'unsupported' if the 'subdir-objects'
>>  option is not specified.  This should give the users enough forewarning
>>  about the planned change, and give them time to update their packages
>>  to the new semantic.
> 
> Hi Stefano,
> 
> this warning (given when there are C - or other? - sources in subdirs)
> should also mention the need to use AM_PROG_CC_C_O.
> 
Agreed.  And glad I brought this planned change up on the list; I have
already got two good suggestions for things that I should have thought
by myself -- but alas, I didn't.  So, thanks guys!

Before proceeding with an attempted implementation in the next days, I
will prepare a brief summary of this discussion in the PLANS directory
(and post it on the list for reference).

In the meantime, of course, further feedback or suggestions are very
welcome.

Thanks,
  Stefano

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Breitenlohner <peb <at> mppmu.mpg.de>
Cc: bug-automake <at> gnu.org, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 13:17:05 +0100

On 01/08/2013 11:35 AM, Stefano Lattarini wrote:
>>
>> this warning (given when there are C - or other? - sources in subdirs)
>> should also mention the need to use AM_PROG_CC_C_O.
>>
> Agreed.
>
Actually, the warning about a missing AM_PROG_CC_C_O will be automatically
given once the user has added 'subdir-objects' to the AUTOMAKE_OPTIONS.

  - the user sees the warning about missing 'subdir-objects' option;
  - he adds it to AM_INIT_AUTOMAKE, and calls "autoreconf";
  - he now sees the warning about AM_PROG_CC_C_O that is now triggered
    by the presence of 'subdir-objects';
  - he add AM_PROG_CC_C_O to configure.ac, and calls autoreconf.

However, I see that it would be nice to try to be smarter and give
the warning right away, to save the user that potentially annoy
second bootstrap.  So I still think your suggestion is a good idea.

Thanks,
  Stefano

Message #35 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Peter Breitenlohner <peb <at> mppmu.mpg.de>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 8 Jan 2013 09:53:20 -0500

On 2013-01-08 13:17 +0100, Stefano Lattarini wrote:
> Actually, the warning about a missing AM_PROG_CC_C_O will be automatically
> given once the user has added 'subdir-objects' to the AUTOMAKE_OPTIONS.
> 
>   - the user sees the warning about missing 'subdir-objects' option;
>   - he adds it to AM_INIT_AUTOMAKE, and calls "autoreconf";
>   - he now sees the warning about AM_PROG_CC_C_O that is now triggered
>     by the presence of 'subdir-objects';
>   - he add AM_PROG_CC_C_O to configure.ac, and calls autoreconf.
> 
> However, I see that it would be nice to try to be smarter and give
> the warning right away, to save the user that potentially annoy
> second bootstrap.  So I still think your suggestion is a good idea.

I don't think AM_PROG_CC_C_O is optional at all when subdir-objects is
enabled.  Even with a single source file in a the same directory as the
Makefile, Automake is generating a suffix rule that looks like this:

  .c.o:
  [...]
  @am__fastdepCC_FALSE@	$(COMPILE) -c -o $@ $<

which looks like it's using -c and -o together to me.  So if
subdir-objects is made mandatory, AM_PROG_CC_C_O will become mandatory
as well, so AM_INIT_AUTOMAKE may as well just call it automatically.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Message #38 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> elliptictech.com>
Cc: Peter Breitenlohner <peb <at> mppmu.mpg.de>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 16:15:49 +0100

Hi Nick.

On 01/08/2013 03:53 PM, Nick Bowler wrote:
> On 2013-01-08 13:17 +0100, Stefano Lattarini wrote:
>> Actually, the warning about a missing AM_PROG_CC_C_O will be automatically
>> given once the user has added 'subdir-objects' to the AUTOMAKE_OPTIONS.
>>
>>   - the user sees the warning about missing 'subdir-objects' option;
>>   - he adds it to AM_INIT_AUTOMAKE, and calls "autoreconf";
>>   - he now sees the warning about AM_PROG_CC_C_O that is now triggered
>>     by the presence of 'subdir-objects';
>>   - he add AM_PROG_CC_C_O to configure.ac, and calls autoreconf.
>>
>> However, I see that it would be nice to try to be smarter and give
>> the warning right away, to save the user that potentially annoy
>> second bootstrap.  So I still think your suggestion is a good idea.
> 
> I don't think AM_PROG_CC_C_O is optional at all when subdir-objects is
> enabled.
>
I seem to recall differently (in fact, in Automake-NG, 'subdir-objects'
has already been made mandatory, and that didn't require adding
AM_PROG_CC_C_O to all the configure.ac of tests doing compilation of
C files).  To be really sure, though, I'll have to double-check.  If
you are right, we should try to avoid requiring AM_PROG_CC_C_O for
projects that do not actually need it (that is, that don't use per-target
flags and don't have sources in subdirectories, independently of whether
they set the 'subdir-objects' option or not).

> Even with a single source file in a the same directory as the
> Makefile, Automake is generating a suffix rule that looks like this:
>
>   .c.o:
>   [...]
>   @am__fastdepCC_FALSE@	$(COMPILE) -c -o $@ $<
> 
> which looks like it's using -c and -o together to me.
>
This seems indeed wrong.  Can you send a minimal reproducer for this
issue?

> So if subdir-objects is made mandatory, AM_PROG_CC_C_O will become
> mandatory as well, so AM_INIT_AUTOMAKE may as well just call it
> automatically.
>
That would be overkill, since AM_PROG_CC_C_O is only required by
projects doing C compilation.  Also, IIRC, that macro needs to be
called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
before AC_PROG_CC.  In addition, AM_PROG_CC_C_O is not required by
projects that don't care about catering to inferior compilers.

In conclusion, even if you are right in the first part of your mail,
the sanest policy is to simply continue to give a warning in the
"portability" category if AM_PROG_CC_C_O is not used in a project
doing C compilation.

Regards,
  Stefano

Message #41 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 08:29:57 -0700

[Message part 1 (text/plain, inline)]

On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
> That would be overkill, since AM_PROG_CC_C_O is only required by
> projects doing C compilation.  Also, IIRC, that macro needs to be
> called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
> before AC_PROG_CC.

But with m4, you can arrange for AM_INIT_AUTOMAKE to redefine AC_PROG_CC
so that it hooks in a call to AM_PROG_CC_C_O immediately after its
current definition, and thus still preserve desired ordering while
making the burden simpler for the configure.ac author.

>  In addition, AM_PROG_CC_C_O is not required by
> projects that don't care about catering to inferior compilers.

How much speed penalty and configure bloat are we talking about by
allowing projects to omit the use of this macro if they don't care about
inferior compilers?  Is anyone really going to complain if we switch to
always supporting inferior compilers?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #44 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Peter Breitenlohner <peb <at> mppmu.mpg.de>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 8 Jan 2013 11:00:41 -0500

On 2013-01-08 16:15 +0100, Stefano Lattarini wrote:
> On 01/08/2013 03:53 PM, Nick Bowler wrote:
[...]
> > I don't think AM_PROG_CC_C_O is optional at all when subdir-objects is
> > enabled.
>
> I seem to recall differently (in fact, in Automake-NG, 'subdir-objects'
> has already been made mandatory, and that didn't require adding
> AM_PROG_CC_C_O to all the configure.ac of tests doing compilation of
> C files).  To be really sure, though, I'll have to double-check.  If
> you are right, we should try to avoid requiring AM_PROG_CC_C_O for
> projects that do not actually need it (that is, that don't use per-target
> flags and don't have sources in subdirectories, independently of whether
> they set the 'subdir-objects' option or not).

That would be fine, but I wonder if the code to "optimize" subdir-objects
would actually be any simpler than just keeping subdir-objects as an
option...

> > Even with a single source file in a the same directory as the
> > Makefile, Automake is generating a suffix rule that looks like this:
> >
> >   .c.o:
> >   [...]
> >   @am__fastdepCC_FALSE@	$(COMPILE) -c -o $@ $<
> > 
> > which looks like it's using -c and -o together to me.
>
> This seems indeed wrong.  Can you send a minimal reproducer for this
> issue?

Well, the rule itself does not look wrong.  The -o $@ is required for
this suffix rule to work properly with subdir-objects -- otherwise, the
suffix rule would have the compiler place its output in the working
directory which is even more wrong.

But anyway, here's the test case I used (I've not had a chance to
install 1.13 yet, so I only tested it on 1.11.6 and 1.12.6):

  % cat >configure.ac <<'EOF'
AC_INIT([test], [0])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF

  % cat >Makefile.am <<'EOF'
bin_PROGRAMS = foo
EOF

  % cat >foo.c <<'EOF'
int main(void) { return 0; }
EOF

> > So if subdir-objects is made mandatory, AM_PROG_CC_C_O will become
> > mandatory as well, so AM_INIT_AUTOMAKE may as well just call it
> > automatically.
>
> That would be overkill, since AM_PROG_CC_C_O is only required by
> projects doing C compilation.  Also, IIRC, that macro needs to be
> called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
> before AC_PROG_CC.

These are very good points that I had not considered.  But I don't
think they are unsurmountable.  It should be straightforward to have
AM_INIT_AUTOMAKE arrange (using AC_CONFIG_COMMANDS_PRE) for
AM_PROG_CC_C_O to be called later, and only if it's appropriate to
do so.  I can probably cook up an example later.

> In addition, AM_PROG_CC_C_O is not required by projects that don't
> care about catering to inferior compilers.

Since the AC_PROG_CC_C_O test is so trivial, I don't think Automake
should should care about catering to projects that don't care about
catering to inferior compilers.  If such projects really, really want to
avoid the test, they can do m4_define([AM_PROG_CC_C_O]).

> In conclusion, even if you are right in the first part of your mail,
> the sanest policy is to simply continue to give a warning in the
> "portability" category if AM_PROG_CC_C_O is not used in a project
> doing C compilation.

Hm, I think the sanest policy is for Automake to automatically do the
right thing when it is possible to do so.

Chers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Message #47 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> elliptictech.com>
Cc: Peter Breitenlohner <peb <at> mppmu.mpg.de>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 20:20:35 +0100

[+cc automake-patches]

Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>

On 01/08/2013 05:00 PM, Nick Bowler wrote:
> On 2013-01-08 16:15 +0100, Stefano Lattarini wrote:
>> On 01/08/2013 03:53 PM, Nick Bowler wrote:
> [...]
>>> I don't think AM_PROG_CC_C_O is optional at all when subdir-objects is
>>> enabled.
>>
>> I seem to recall differently (in fact, in Automake-NG, 'subdir-objects'
>> has already been made mandatory, and that didn't require adding
>> AM_PROG_CC_C_O to all the configure.ac of tests doing compilation of
>> C files).  To be really sure, though, I'll have to double-check.  If
>> you are right, we should try to avoid requiring AM_PROG_CC_C_O for
>> projects that do not actually need it (that is, that don't use per-target
>> flags and don't have sources in subdirectories, independently of whether
>> they set the 'subdir-objects' option or not).
> 
> That would be fine, but I wonder if the code to "optimize" subdir-objects
> would actually be any simpler than just keeping subdir-objects as an
> option...
>
I think yes.  Also, this discussion has already uncovered at least one
bug in automake (see below), so it's good keeping the ball rolling on
this, IMO.

>>> Even with a single source file in a the same directory as the
>>> Makefile, Automake is generating a suffix rule that looks like this:
>>>
>>>   .c.o:
>>>   [...]
>>>   @am__fastdepCC_FALSE@	$(COMPILE) -c -o $@ $<
>>>
>>> which looks like it's using -c and -o together to me.
>>
>> This seems indeed wrong.  Can you send a minimal reproducer for this
>> issue?
> 
> Well, the rule itself does not look wrong.  The -o $@ is required for
> this suffix rule to work properly with subdir-objects -- otherwise, the
> suffix rule would have the compiler place its output in the working
> directory which is even more wrong.
> 
Unless the source is in the the current directory.  Which is why, even
when the 'subdir-objects' option was active, Automake didn't complain
if AM_PROG_CC_C_O wasn't invoked, *if* it could determine that all the
source files were in the "current" directory.  Good in theory, but as
you've discovered below, wrong in practice ...

> But anyway, here's the test case I used (I've not had a chance to
> install 1.13 yet, so I only tested it on 1.11.6 and 1.12.6):
> 
>   % cat >configure.ac <<'EOF'
> AC_INIT([test], [0])
> AM_INIT_AUTOMAKE([foreign subdir-objects])
> AC_PROG_CC
> AC_CONFIG_FILES([Makefile])
> AC_OUTPUT
> EOF
>
Yeah, I can reproduce the issue :-(  See test case below, which I
will commit shortly (comments are welcome).

It is indeed a bug that Automake does not require AM_PROG_CC_C_O but
uses "-c -o" anyway in the generated rules.  This should be fixed in
1.13.2.  I will elaborate further in the upcoming reply to Eric's
last message.

>   % cat >Makefile.am <<'EOF'
> bin_PROGRAMS = foo
> EOF
> 
>   % cat >foo.c <<'EOF'
> int main(void) { return 0; }
> EOF
> 
>>> So if subdir-objects is made mandatory, AM_PROG_CC_C_O will become
>>> mandatory as well, so AM_INIT_AUTOMAKE may as well just call it
>>> automatically.
>>
>> That would be overkill, since AM_PROG_CC_C_O is only required by
>> projects doing C compilation.  Also, IIRC, that macro needs to be
>> called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
>> before AC_PROG_CC.
> 
> These are very good points that I had not considered.  But I don't
> think they are unsurmountable.  It should be straightforward to have
> AM_INIT_AUTOMAKE arrange (using AC_CONFIG_COMMANDS_PRE) for
> AM_PROG_CC_C_O to be called later, and only if it's appropriate to
> do so.  I can probably cook up an example later.
>
If you feel like doing so, it would be welcome.  A patch would be
even more so ;-)

>> In addition, AM_PROG_CC_C_O is not required by projects that don't
>> care about catering to inferior compilers.
> 
> Since the AC_PROG_CC_C_O test is so trivial, I don't think Automake
> should should care about catering to projects that don't care about
> catering to inferior compilers.
>
After reviewing the AC_PROG_CC_C_O implementation, I agree.

> If such projects really, really want to
> avoid the test, they can do m4_define([AM_PROG_CC_C_O]).
>
Agreed.

>> In conclusion, even if you are right in the first part of your mail,
>> the sanest policy is to simply continue to give a warning in the
>> "portability" category if AM_PROG_CC_C_O is not used in a project
>> doing C compilation.
> 
> Hm, I think the sanest policy is for Automake to automatically do the
> right thing when it is possible to do so.
> 
Alas, you are right again -- more work for us to do :-)

Thanks,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From d3b48d5e1d9c50972340a978a0c9cea2154b562e Mon Sep 17 00:00:00 2001
Message-Id: <d3b48d5e1d9c50972340a978a0c9cea2154b562e.1357672750.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Tue, 8 Jan 2013 20:19:04 +0100
Subject: [PATCH] coverage: compile rules used "-c -o" also with losing
 compilers

If the 'subdir-objects' option is used, Automake-generated rules for
C compilation pass both the "-c" and "-o" options to the C compiler,
*unconditionally*.  There are some compilers that choke on such an
usage, but the AM_PROG_CC_C_O macro takes care of them (it does so by
redefining $CC to use the Automake-provided 'compile' wrapper script
automatically, if a losing compiler is detected at configure runtime).

Unfortunately, in case the 'subdir-objects' option is specified in a
Makefile.am, but all the source files resided anyway in the top-level
directory (relative to the Makefile.am), Automake do *not* complain
if AM_PROG_CC_C_O wasn't invoked in 'configure.ac' -- all the while
still passing "-c -o" to the compiler invocations.  This could cause
compilation failures with losing compilers if the user forget to call
AM_PROG_CC_C_O in 'configure.ac' (and Automake would not warn him of
the issue).

Expose this bug in the testsuite.

Issue identified by Nick Bowler in the discussion on automake bug#13378:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>

* t/ccnoco4.sh: New test.
* t/list-of-tests.mk: List it.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 t/ccnoco4.sh       | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 t/list-of-tests.mk |  1 +
 2 files changed, 71 insertions(+)
 create mode 100755 t/ccnoco4.sh

diff --git a/t/ccnoco4.sh b/t/ccnoco4.sh
new file mode 100755
index 0000000..54b857a
--- /dev/null
+++ b/t/ccnoco4.sh
@@ -0,0 +1,70 @@
+#! /bin/sh
+# Copyright (C) 2001-2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Check that Automake doesn't pass "-c -o" to  losing compiler when
+# the 'subdir-objects' is used but sources are only present in the
+# top-level directory.  Reported by Nick Bowler in the discussion on
+# automake bug#13378:
+# <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
+# <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>
+
+required=gcc
+. test-init.sh
+
+# We deliberately do not call AM_PROG_CC_C_O here.
+cat >> configure.ac << 'END'
+AC_PROG_CC
+$CC --version; $CC -v; # For debugging.
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
+bin_PROGRAMS = foo bar
+bar_SOURCES = foo.c
+END
+
+echo 'int main (void) { return 0; }' > foo.c
+
+cat > Mycomp << END
+#!/bin/sh
+
+case " \$* " in
+ *\ -c*\ -o* | *\ -o*\ -c*)
+    exit 1
+    ;;
+esac
+
+# Use '$CC', not 'gcc', to honour the compiler chosen
+# by the testsuite setup.
+exec $CC "\$@"
+END
+
+chmod +x Mycomp
+
+# Make sure the compiler doesn't understand '-c -o'.
+CC=$(pwd)/Mycomp
+export CC
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --copy --add-missing
+
+./configure
+$MAKE
+$MAKE distcheck
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index f3e9963..e0d86b7 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -209,6 +209,7 @@ t/canon-name.sh \
 t/ccnoco.sh \
 t/ccnoco2.sh \
 t/ccnoco3.sh \
+t/ccnoco4.sh \
 t/check.sh \
 t/check2.sh \
 t/check4.sh \
-- 
1.8.1.rc3.192.g2d0029e

Message #50 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 20:27:52 +0100

On 01/08/2013 04:29 PM, Eric Blake wrote:
> On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
>> That would be overkill, since AM_PROG_CC_C_O is only required by
>> projects doing C compilation.  Also, IIRC, that macro needs to be
>> called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
>> before AC_PROG_CC.
> 
> But with m4, you can arrange for AM_INIT_AUTOMAKE to redefine AC_PROG_CC
> so that it hooks in a call to AM_PROG_CC_C_O immediately after its
> current definition, and thus still preserve desired ordering while
> making the burden simpler for the configure.ac author.
>
This is true, but I'd have preferred to avoid this shenanigans with
macro redefinitions if at all possible.  It seems it won't be really
possible though (see also my reply to the last message from Nick):
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>
:-(

>>  In addition, AM_PROG_CC_C_O is not required by
>> projects that don't care about catering to inferior compilers.
> 
> How much speed penalty and configure bloat are we talking about by
> allowing projects to omit the use of this macro if they don't care about
> inferior compilers?
>
Almost zero bloat.  The code simply re-uses a cache variable set by
AC_PROG_CC, and, *for losing compilers only*, plays some dirty but
inexpensive tricks with $CC redefinition.

So I think your proposal is the way to go, *right for Automake 1.13.2*,
since it offers a bug fix for the situation described in
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>

AM_PROG_CC_C_O should be kept as a no-op for the moment, but deprecated
*in documentation only* as no longer useful, and then, maybe, starting
from Automake 1.14, deprecated also by non-fatal runtime warnings.

Further suggestions, examples or patches would be very welcome (just
ping me if you plan to attempt a patch, to avoid unwitting duplication
of efforts).

Thanks,
  Stefano

Message #53 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 22:06:55 +0100

On 2013-01-08 16:15, Stefano Lattarini wrote:
> That would be overkill, since AM_PROG_CC_C_O is only required by
> projects doing C compilation.

Hi,

However, a notorious C++ compiler from Redmond is inferior also in its
C++ mode and would benefit from an AM_PROG_CXX_C_O variant. If the
meat of AM_PROG_CC_C_O becomes part of AC_PROG_CC if would be nice
if $CXX could be edited to wrap an inferior C++ compiler in AC_PROG_CXX.
I.e. in similar fashion to how $CC would be edited in AC_PROG_CC.

Cheers,
Peter

Message #56 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, Eric Blake <eblake <at> redhat.com>,
	13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 22:11:47 +0100

On 2013-01-08 20:27, Stefano Lattarini wrote:
> On 01/08/2013 04:29 PM, Eric Blake wrote:
>> On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
>>>  In addition, AM_PROG_CC_C_O is not required by
>>> projects that don't care about catering to inferior compilers.
>>
>> How much speed penalty and configure bloat are we talking about by
>> allowing projects to omit the use of this macro if they don't care about
>> inferior compilers?
>>
> Almost zero bloat.  The code simply re-uses a cache variable set by
> AC_PROG_CC, and, *for losing compilers only*, plays some dirty but
> inexpensive tricks with $CC redefinition.

Not quite, the cache variable is from AC_PROG_CC_C_O which is is not
invoked by AC_PROG_CC, at least I don't think so? AM_PROG_CC_C_O
requires AC_PROG_CC_C_O so it costs a couple of extra compile tests.
Not that I'm complaining if those tests are always performed though,
just trying to keep the arguments honest...

(but again, I haven't actually checked if AC_PROG_CC triggers
AC_PROG_CC_C_O)

Cheers,
Peter

Message #59 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, Eric Blake <eblake <at> redhat.com>,
	13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 22:28:44 +0100

On 01/08/2013 10:11 PM, Peter Rosin wrote:
> On 2013-01-08 20:27, Stefano Lattarini wrote:
>> On 01/08/2013 04:29 PM, Eric Blake wrote:
>>> On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
>>>>  In addition, AM_PROG_CC_C_O is not required by
>>>> projects that don't care about catering to inferior compilers.
>>>
>>> How much speed penalty and configure bloat are we talking about by
>>> allowing projects to omit the use of this macro if they don't care about
>>> inferior compilers?
>>>
>> Almost zero bloat.  The code simply re-uses a cache variable set by
>> AC_PROG_CC, and, *for losing compilers only*, plays some dirty but
>> inexpensive tricks with $CC redefinition.
> 
> Not quite, the cache variable is from AC_PROG_CC_C_O which is is not
> invoked by AC_PROG_CC, at least I don't think so? AM_PROG_CC_C_O
> requires AC_PROG_CC_C_O so it costs a couple of extra compile tests.
>
Ouch.  Thanks for correcting me on this.

> Not that I'm complaining if those tests are always performed though,
> just trying to keep the arguments honest...
>
Alas, I wasn't being dishonest here, just dumb/distracted ;-)

> (but again, I haven't actually checked if AC_PROG_CC triggers
> AC_PROG_CC_C_O)
> 
Nope.  Maybe it could do so in future Autoconf version though?
This would be a good occasion to fix some weird AC_PROG_CC_C_O
behaviours (e.g., the fact that it's checking both "cc" and
"$CC").  Eric, WDYT?

Regards,
  Stefano

Message #62 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 22:42:56 +0100

On 01/08/2013 10:06 PM, Peter Rosin wrote:
> On 2013-01-08 16:15, Stefano Lattarini wrote:
>> That would be overkill, since AM_PROG_CC_C_O is only required by
>> projects doing C compilation.
> 
> Hi,
> 
> However, a notorious C++ compiler from Redmond is inferior also in its
> C++ mode and would benefit from an AM_PROG_CXX_C_O variant.
>
No hope the unnamed company producing this compiler would listen to a
bug report? ;-)

> If the meat of AM_PROG_CC_C_O becomes part of AC_PROG_CC if would
> be nice if $CXX could be edited to wrap an inferior C++ compiler in
> AC_PROG_CXX.
>
That would require an AC_PROG_CXX_C_O in Autoconf first (well, not
actually require, but that's the avenue I'd prefer).

Then again, in the longer term, wouldn't it be better to provide a
(GNU or non-GNU) package meant to wrap all this MSVC incompatibilities
in a secluded place, instead of having Automake chase all this
intricacies with mixed fortune?  After all, we don't have random users
building on MSYS with MSVC -- the users interested in doing so should
know what they are doing, so we could ask them to install this
hypothetical "wrapping package" before trying any such compilation.
It might also be made part of MSYS itself eventually, if it proves
itself on field.

Good idea, bad idea, or simple wishful thinking?

> I.e. in similar fashion to how $CC would be edited in AC_PROG_CC.
> 
> Cheers,
> Peter
> 

Regards,
 Stefano

Message #65 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 23:03:01 +0100

On 2013-01-08 22:42, Stefano Lattarini wrote:
> On 01/08/2013 10:06 PM, Peter Rosin wrote:
>> On 2013-01-08 16:15, Stefano Lattarini wrote:
>>> That would be overkill, since AM_PROG_CC_C_O is only required by
>>> projects doing C compilation.
>>
>> Hi,
>>
>> However, a notorious C++ compiler from Redmond is inferior also in its
>> C++ mode and would benefit from an AM_PROG_CXX_C_O variant.
>>
> No hope the unnamed company producing this compiler would listen to a
> bug report? ;-)

It wouldn't help to just add support for "-o <output>". The MSVC compiler
needs the compile script for other reasons as well. There was a discussion
earlier about A[CM]_PROG_CXX_C_O where an idea was expressed to split it
in two parts, a simple front-end and a back-end doing the work, so that a
second front-end (piggybacking on the back-end) could be added when the
compile script is needed for other reasons than -c -o support. Nothing
have materialized from that discussion so far though... (which is my fault)

Also, I'm sure others before me have wished for a POSIX compliant CLI.

>> If the meat of AM_PROG_CC_C_O becomes part of AC_PROG_CC if would
>> be nice if $CXX could be edited to wrap an inferior C++ compiler in
>> AC_PROG_CXX.
>>
> That would require an AC_PROG_CXX_C_O in Autoconf first (well, not
> actually require, but that's the avenue I'd prefer).
> 
> Then again, in the longer term, wouldn't it be better to provide a
> (GNU or non-GNU) package meant to wrap all this MSVC incompatibilities
> in a secluded place, instead of having Automake chase all this
> intricacies with mixed fortune?  After all, we don't have random users
> building on MSYS with MSVC -- the users interested in doing so should
> know what they are doing, so we could ask them to install this
> hypothetical "wrapping package" before trying any such compilation.
> It might also be made part of MSYS itself eventually, if it proves
> itself on field.
> 
> Good idea, bad idea, or simple wishful thinking?

I think it's a bad idea. Trying to do this outside of autotools will
just grow forks. Try finding a canonical cccl script on the Internet...

Cheers,
Peter'

Message #70 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the
	default, and only available one
Date: Tue, 08 Jan 2013 23:32:26 +0100

On 01/08/2013 11:03 PM, Peter Rosin wrote:
>
> [BIG SNIP]
>
>> Then again, in the longer term, wouldn't it be better to provide a
>> (GNU or non-GNU) package meant to wrap all this MSVC incompatibilities
>> in a secluded place, instead of having Automake chase all this
>> intricacies with mixed fortune?  After all, we don't have random users
>> building on MSYS with MSVC -- the users interested in doing so should
>> know what they are doing, so we could ask them to install this
>> hypothetical "wrapping package" before trying any such compilation.
>> It might also be made part of MSYS itself eventually, if it proves
>> itself on field.
>>
>> Good idea, bad idea, or simple wishful thinking?
> 
> I think it's a bad idea.  Try finding a canonical cccl script on the
> Internet...  Trying to do this outside of autotools will just grow
> forks.
>
Then what about doing it in the Autotools?  That is, let's continue
to carry the ar-lib, compile, etc. scripts in our tree, let's continue
to distribute them in the client packages tarballs, but admit that
the setups they cater for are today special and/or corner case enough
that we don't need to "automagically" detect them; instead, let's the
user explicitly ask for their use (with an environment variable? with
a configure options? not sure).  We'll have less time-wasting and
complex probing logic, but still a tight integration, and no risk
of proliferating forks.

Of course, this could create yet more compatibility and/or transition
and/or deprecation headaches.  So, all things considered, it might
be a poor trade-off.  Hmmm...

Well, let's put this idea in the back-burner for now.  We still have
a confirmed bug to fix, before doing anything else ;-)

Regards,
 Stefano

Message #73 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: [PATCH] compile: use 'compile' script when "-c -o" is used with losing
	compilers
Date: Thu, 10 Jan 2013 14:33:19 +0100

Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>

On 01/08/2013 08:27 PM, Stefano Lattarini wrote:
> On 01/08/2013 04:29 PM, Eric Blake wrote:
>> On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
>>> That would be overkill, since AM_PROG_CC_C_O is only required by
>>> projects doing C compilation.  Also, IIRC, that macro needs to be
>>> called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
>>> before AC_PROG_CC.
>>
>> But with m4, you can arrange for AM_INIT_AUTOMAKE to redefine AC_PROG_CC
>> so that it hooks in a call to AM_PROG_CC_C_O immediately after its
>> current definition, and thus still preserve desired ordering while
>> making the burden simpler for the configure.ac author.
>>
> This is true, but I'd have preferred to avoid this shenanigans with
> macro redefinitions if at all possible.  It seems it won't be really
> possible though (see also my reply to the last message from Nick):
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>
> :-(
>
> [SNIP]
>
> So I think your proposal is the way to go, *right for Automake 1.13.2*,
> since it offers a bug fix for the situation described in
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>
>
Done with the patch below.  The AC_PROG_CC redefinition is more of a
band-aid rather than a "proper" fix (the copy & paste done by the patch
is admittedly quite horrific), but that is no big deal IMHO, since we
will backport the features needed by Automake back into Autoconf, and
Automake 1.14 will just require the later Autoconf anyway, allowing us
to get rid of that copy & paste.

In addition, with this change, the 'compile' script will be required
in *all* projects using C compilation (even if they don't use the
'subdir-objects' option); but this should be noticeable only by
packages not using 'automake --add-missing' (and they should be the
great majority), and easily fixable by the other packages anyway.

OK to push to maint?  I'll wait up to a week to push, since I'd really
like a review on this ...

Thanks,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From 5e65e237be62efabcdc2dbd7410ab44bc514b48e Mon Sep 17 00:00:00 2001
Message-Id: <5e65e237be62efabcdc2dbd7410ab44bc514b48e.1357824420.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Wed, 9 Jan 2013 23:16:53 +0100
Subject: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers

Do so seen when only source files in the "current" directory are present.

This commit is part of a series of related changes addressing automake
bug#13378 (see also the plan 'PLANS/subdir-objects.txt').

Before this change, Automake-generated C compilation rules mistakenly
passed the "-c -o" options combination unconditionally (even to losing
compiler) when the 'subdir-objects' was used but sources were only
present in the top-level directory.  Issue spotted by Nick Bowler:

  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>

We fix this by having Automake redefine AC_PROG_CC to take over the role
of AM_PROG_CC_C_O and to require the 'compile' script unconditionally
(albeit that will continue to be invoked only when inferior compilers
are detected).

Among other things, this means AM_PROG_CC_C_O explicitly is no longer
required; that macro is still supported for backward-compatibility, but
calling it is basically a no-op now.

This change has some pros and some cons (obviously, we believe the former
outweighs the latter).  Here are the most relevant ones:

+ Pros 1:
  Some logic in the Automake script has been simplified
+ Pros 2:
  That simplification has automatically fixed an actual bug (admittedly,
  it was present only in corner situations, but still) XXX
  The test 't/ccnoco4.sh', which demonstrated that bug and has been
  failing so far, now passes.
+ Pros 3:
  Things works more "automagically" now (no need to manually add the
  AM_PROG_CC_C_O macro to configure.ac anymore)

* Cons 1:
  The 'compile' script will be required in all projects using C
  compilation; this will only be a problem for packages not using
  '--add-missing'.  However, such packages are definitely more rare
  than the ones using '--add-missing', and adjusting them will be
  trivial -- just copy the compile script over from the new Automake
  installation.
* Cons 2:
  The copy & paste of autoconf internals hack this change has introduced
  in our "rewrite" of AC_PROG_CC is really an egregious abomination.  It
  can only be justified with the fact that we expect future versions of
  autoconf to implement the semantics we need directly in AC_PROG_CC, so
  that we'll be able to leverage that (since Automake 1.14 will require
  the latest Autoconf version released).

Now, the detailed list of file-by-file changes ...

* automake.in ($seen_cc_c_o): Remove this global variable.
(scan_autoconf_traces): Don't set it, and do not trace the
'AM_PROG_CC_C_O' m4 macro.
(lang_c_rewrite): Remove, no longer needed.
* doc/automake.texi: Adjust expected "autoreconf --install" output
in the amhello example.  Remove statements about the need for the
AM_PROG_CC_C_O macro.  Report it is obsolete now.
* m4/init.m4: Re-write AC_PROG_CC to append checks about whether the
C compiler supports "-c -o" together.  These checks have basically
been ripped out (with adaptations) from the 'AC_PROG_CC_C_O' macro
of Autoconf and ...
* m4/minuso.m4 (AM_PROG_CC_C_O): ... this macro of ours, which has
thus basically become a no-op.
* t/ax/am-test-lib.sh (am_setup_testdir): Also copy the 'compile'
script in the test directory; if we don't do so, every test using
AC_PROG_CC should call automake with the "--add-missing" option, or
copy the 'compile' script itself.
* t/cond11.sh: No need to create a dummy 'compile' script: that is
already brought in by 'am_setup_testdir()', that is automatically
invoked when 'test-lib.sh' is sourced.
* t/add-missing.tap: Adjust: we expect the 'compile' script to be
required by a mere AC_PROG_CC call now.
* t/dist-auxdir-many-subdirs.sh: Likewise.
* t/specflg6.sh: Likewise.
* t/subobj4.sh: Likewise.
* t/cxx-lt-demo.sh: Likewise, and update comments to match.
* t/distcom2.sh: Enhance a little.
* t/dollarvar2.sh: Adjust.
* t/extra-portability.sh: Likewise.
* t/per-target-flags.sh: Likewise.
* t/subobj.sh: Likewise, and enhance a little.
* t/ccnoco2.sh: Remove as obsolete.
* t/list-of-tests.mk (handwritten_TESTS): Adjust.
(XFAIL_TESTS): Remove 't/ccnoco4.sh'.
* NEWS: Update.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 .gitignore                    |  1 +
 NEWS                          | 23 ++++++++++++++++++
 automake.in                   | 47 ------------------------------------
 doc/automake.texi             | 22 +++++++++--------
 m4/init.m4                    | 47 ++++++++++++++++++++++++++++++++++++
 m4/minuso.m4                  | 20 +++-------------
 t/add-missing.tap             |  9 ++++---
 t/ax/am-test-lib.sh           |  2 +-
 t/ccnoco2.sh                  | 55 -------------------------------------------
 t/cond11.sh                   |  1 -
 t/cxx-lt-demo.sh              |  6 +++--
 t/dist-auxdir-many-subdirs.sh |  1 +
 t/distcom2.sh                 |  2 ++
 t/dollarvar2.sh               | 11 +++------
 t/extra-portability.sh        | 13 +++++-----
 t/list-of-tests.mk            |  2 --
 t/per-target-flags.sh         |  7 ------
 t/specflg6.sh                 |  2 --
 t/subobj.sh                   |  5 +++-
 t/subobj4.sh                  |  1 -
 20 files changed, 113 insertions(+), 164 deletions(-)
 delete mode 100755 t/ccnoco2.sh

diff --git a/.gitignore b/.gitignore
index a32310e..0d031eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,6 +33,7 @@
 /doc/amhello/config.h.in~
 /doc/amhello/configure
 /doc/amhello/depcomp
+/doc/amhello/compile
 /doc/amhello/install-sh
 /doc/amhello/missing
 /doc/web-manual
diff --git a/NEWS b/NEWS
index 02a34df..e87d267 100644
--- a/NEWS
+++ b/NEWS
@@ -49,6 +49,29 @@ New in 1.13.2:
     should take precedence over the same-named automake-provided macro
     (defined in '/usr/local/share/aclocal-1.14/vala.m4').

+* C compilation, and the AC_PROG_CC and AM_PROG_CC_C_O macros:
+
+  - The 'compile' script is now unconditionally required for all
+    packages that perform C compilation (note that if you are using
+    the '--add-missing' option, automake will fetch that script for
+    you, so you shouldn't need any explicit adjustment).
+    This new behaviour is needed to avoid obscure errors when the
+    'subdir-objects' option is used, and the compiler is an inferior
+    one that doesn't grasp the combined use of both the "-c -o"
+    options; see discussion about automake bug#13378 for more details:
+    <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
+    <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>
+
+  - Automake will automatically enhance the AC_PROG_CC autoconf macro
+    to make it check, at configure time, that the C compiler supports
+    the combined use of both the "-c -o" options.  This "rewrite" of
+    AC_PROG_CC is only meant to be temporary, since future Autoconf
+    versions should provide all the features Automake needs.
+
+  - The AM_PROG_CC_C_O is no longer useful, and its use is a no-op
+    now.  Future Automake versions might start warning that this
+    macro is obsolete.
+
 * Obsolescent features:

   - Use of suffix-less info files (that can be specified through the
diff --git a/automake.in b/automake.in
index e8ba73f..990b60d 100644
--- a/automake.in
+++ b/automake.in
@@ -387,9 +387,6 @@ my $package_version_location;
 # TRUE if we've seen AM_PROG_AR
 my $seen_ar = 0;

-# TRUE if we've seen AM_PROG_CC_C_O
-my $seen_cc_c_o = 0;
-
 # Location of AC_REQUIRE_AUX_FILE calls, indexed by their argument.
 my %required_aux_file = ();

@@ -5179,7 +5176,6 @@ sub scan_autoconf_traces ($)
 		AM_INIT_AUTOMAKE => 0,
 		AM_MAINTAINER_MODE => 0,
 		AM_PROG_AR => 0,
-		AM_PROG_CC_C_O => 0,
 		_AM_SUBST_NOTMAKE => 1,
 		_AM_COND_IF => 1,
 		_AM_COND_ELSE => 1,
@@ -5383,10 +5379,6 @@ EOF
 	{
 	  $seen_ar = $where;
 	}
-      elsif ($macro eq 'AM_PROG_CC_C_O')
-	{
-	  $seen_cc_c_o = $where;
-	}
       elsif ($macro eq '_AM_COND_IF')
         {
 	  cond_stack_if ('', $args[1], $where);
@@ -5607,45 +5599,6 @@ sub lang_sub_obj
     return option 'subdir-objects' ? LANG_SUBDIR : LANG_PROCESS;
 }

-# Rewrite a single C source file.
-sub lang_c_rewrite
-{
-  my ($directory, $base, $ext, $obj, $have_per_exec_flags, $var) = @_;
-
-  my $r = LANG_PROCESS;
-  if (option 'subdir-objects')
-    {
-      $r = LANG_SUBDIR;
-      if ($directory && $directory ne '.')
-	{
-	  $base = $directory . '/' . $base;
-
-	  # 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.
-	  msg_var ('portability', $var,
-		   "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')
-	    unless $seen_cc_c_o || $obj eq '.lo';
-	}
-    }
-
-  if (! $seen_cc_c_o
-      && $have_per_exec_flags
-      && ! option 'subdir-objects'
-      && $obj ne '.lo')
-    {
-      msg_var ('portability',
-	       $var, "compiling '$base.c' with per-target flags requires "
-	       . "'AM_PROG_CC_C_O' in '$configure_ac'",
-	       uniq_scope => US_GLOBAL,
-	       uniq_part => 'AM_PROG_CC_C_O per-target')
-    }
-
-    return $r;
-}
-
 # Rewrite a single header file.
 sub lang_header_rewrite
 {
diff --git a/doc/automake.texi b/doc/automake.texi
index 8ace5e5..5048f54 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -1496,6 +1496,7 @@ command as follows:
 ~/amhello % @kbd{autoreconf --install}
 configure.ac: installing './install-sh'
 configure.ac: installing './missing'
+configure.ac: installing './compile'
 src/Makefile.am: installing './depcomp'
 @end example

@@ -3994,10 +3995,9 @@ choose the assembler for you (by default the C compiler) and set
 @item AM_PROG_CC_C_O
 @acindex AM_PROG_CC_C_O
 @acindex AC_PROG_CC_C_O
-This is like @code{AC_PROG_CC_C_O}, but it generates its results in
-the manner required by Automake.  You must use this instead of
-@code{AC_PROG_CC_C_O} when you need this functionality, that is, when
-using per-target flags or subdir-objects with C sources.
+This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
+code needs not to use this macro.  It might be deprecated and
+@emph{retired in future Automake versions}.

 @item AM_PROG_LEX
 @acindex AM_PROG_LEX
@@ -4068,6 +4068,13 @@ Invocation, , Using @command{autoupdate} to Modernize

 @table @code

+@item AM_PROG_CC_C_O
+@acindex AM_PROG_CC_C_O
+@acindex AC_PROG_CC_C_O
+This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
+code needs not to use this macro.  It will be deprecated, and then
+removed, in future Automake versions.
+
 @item AM_PROG_MKDIR_P
 @acindex AM_PROG_MKDIR_P
 @cindex @code{mkdir -p}, macro check
@@ -5810,9 +5817,7 @@ different name for the intermediate object files.  Ordinarily a file
 like @file{sample.c} will be compiled to produce @file{sample.o}.
 However, if the program's @code{_CFLAGS} variable is set, then the
 object file will be named, for instance, @file{maude-sample.o}.  (See
-also @ref{Renamed Objects}.)  The use of per-target compilation flags
-with C sources requires that the macro @code{AM_PROG_CC_C_O} be called
-from @file{configure.ac}.
+also @ref{Renamed Objects}).

 In compilations with per-target flags, the ordinary @samp{AM_} form of
 the flags variable is @emph{not} automatically included in the
@@ -10245,9 +10250,6 @@ the source file.  For instance, if the source file is
 @file{subdir/file.cxx}, then the output file would be
 @file{subdir/file.o}.

-In order to use this option with C sources, you should add
-@code{AM_PROG_CC_C_O} to @file{configure.ac}.
-
 @anchor{tar-formats}
 @item @option{tar-v7}
 @itemx @option{tar-ustar}
diff --git a/m4/init.m4 b/m4/init.m4
index 44b2481..db77a96 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -125,6 +125,53 @@ dnl mangled by Autoconf and run in a shell conditional statement.
 m4_define([_AC_COMPILER_EXEEXT],
 m4_defn([_AC_COMPILER_EXEEXT])[m4_provide([_AM_COMPILER_EXEEXT])])

+dnl We have to redefine AC_PROG_CC to allow our compile rules to use
+dnl "-c -o" together also with losing compilers.
+dnl FIXME: Add references to the original discussion and bug report.
+dnl FIXME: Shameless copy & paste from Autoconf internals, since trying to
+dnl        play smart among tangles of AC_REQUIRE, m4_defn, m4_provide and
+dnl        other tricks was proving too difficult, and in the end, likely
+dnl        more brittle too.  And this should anyway be just a temporary
+dnl        band-aid, until Autoconf provides the semantics and/or hooks we
+dnl        need (hint hint, nudge nudge) ...
+AC_DEFUN([AC_PROG_CC],
+m4_defn([AC_PROG_CC])
+[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
+AC_REQUIRE_AUX_FILE([compile])dnl
+dnl FIXME The following abomination is expected to disappear in
+dnl       Automake 1.14.
+AC_MSG_CHECKING([whether $CC understands -c and -o together])
+set dummy $CC; ac_cc=`AS_ECHO(["$[2]"]) | \
+                      sed 's/[[^a-zA-Z0-9_]]/_/g;s/^[[0-9]]/_/'`
+AC_CACHE_VAL([ac_cv_prog_cc_${am_cc}_c_o],
+[AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
+# Make sure it works both with $CC and with simple cc.
+# We do the test twice because some compilers refuse to overwrite an
+# existing .o file with -o, though they will create one.
+ac_try='$CC -c conftest.$ac_ext -o conftest2.$ac_objext >&AS_MESSAGE_LOG_FD'
+rm -f conftest2.*
+if _AC_DO_VAR(ac_try) && test -f conftest2.$ac_objext
+then
+  eval ac_cv_prog_cc_${ac_cc}_c_o=yes
+else
+  eval ac_cv_prog_cc_${ac_cc}_c_o=no
+fi
+rm -f core conftest*
+])dnl
+if eval test \"\$ac_cv_prog_cc_${ac_cc}_c_o\" = yes; then
+  AC_MSG_RESULT([yes])
+else
+  AC_MSG_RESULT([no])
+  # Losing compiler, so wrap it with the 'compile' script.
+  # FIXME: It is wrong to rewrite CC.
+  # But if we don't then we get into trouble of one sort or another.
+  # A longer-term fix would be to have automake use am__CC in this case,
+  # and then we could set am__CC="\$(top_srcdir)/compile \$(CC)"
+  CC="$am_aux_dir/compile $CC"
+  AC_DEFINE([NO_MINUS_C_MINUS_O], [1],
+            [Define to 1 if your C compiler doesn't accept -c and -o together.])
+fi
+])

 # When config.status generates a header, we must update the stamp-h file.
 # This file resides in the same directory as the config header
diff --git a/m4/minuso.m4 b/m4/minuso.m4
index 984427c..6cb574e 100644
--- a/m4/minuso.m4
+++ b/m4/minuso.m4
@@ -7,24 +7,10 @@

 # AM_PROG_CC_C_O
 # --------------
-# Like AC_PROG_CC_C_O, but changed for automake.
+# Basically a no-op now, completely superseded by the AC_PROG_CC
+# adjusted by Automake.  Kept for backward-compatibility.
 AC_DEFUN([AM_PROG_CC_C_O],
-[AC_REQUIRE([AC_PROG_CC_C_O])dnl
-AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
-AC_REQUIRE_AUX_FILE([compile])dnl
-# FIXME: we rely on the cache variable name because
-# there is no other way.
-set dummy $CC
-am_cc=`echo $[2] | sed ['s/[^a-zA-Z0-9_]/_/g;s/^[0-9]/_/']`
-eval am_t=\$ac_cv_prog_cc_${am_cc}_c_o
-if test "$am_t" != yes; then
-   # Losing compiler, so override with the script.
-   # FIXME: It is wrong to rewrite CC.
-   # But if we don't then we get into trouble of one sort or another.
-   # A longer-term fix would be to have automake use am__CC in this case,
-   # and then we could set am__CC="\$(top_srcdir)/compile \$(CC)"
-   CC="$am_aux_dir/compile $CC"
-fi
+[AC_REQUIRE([AC_PROG_CC])dnl
 dnl Make sure AC_PROG_CC is never called again, or it will override our
 dnl setting of CC.
 m4_define([AC_PROG_CC],
diff --git a/t/add-missing.tap b/t/add-missing.tap
index f74c2fd..9c4b774 100755
--- a/t/add-missing.tap
+++ b/t/add-missing.tap
@@ -247,6 +247,7 @@ check_ <<'END'
 depcomp/C
 == Files ==
 depcomp
+compile
 == configure.ac ==
 AC_PROG_CC
 == Makefile.am ==
@@ -271,9 +272,9 @@ compile
 == Files ==
 compile
 == configure.ac ==
-# Using AM_PROG_CC_C_O in configure.ac should be enough.  No need to
-# use AC_PROG_CC too, nor to define xxx_PROGRAMS in Makefile.am.
-AM_PROG_CC_C_O
+# Using AC_PROG_CC in configure.ac should be enough.  No
+# need to also define, say, xxx_PROGRAMS in Makefile.am.
+AC_PROG_CC
 END

 # For config.guess and config.sub.
@@ -294,6 +295,7 @@ check_ <<'END'
 == Name ==
 ylwrap/Lex
 == Files ==
+compile
 ylwrap
 == configure.ac ==
 AC_PROG_CC
@@ -308,6 +310,7 @@ check_ <<'END'
 == Name ==
 ylwrap/Yacc
 == Files ==
+compile
 ylwrap
 == configure.ac ==
 AC_PROG_CC
diff --git a/t/ax/am-test-lib.sh b/t/ax/am-test-lib.sh
index f3fcacc..0ceb4d0 100644
--- a/t/ax/am-test-lib.sh
+++ b/t/ax/am-test-lib.sh
@@ -820,7 +820,7 @@ am_setup_testdir ()
     || framework_failure_ "cannot chdir into test subdirectory"
   if test x"$am_create_testdir" != x"empty"; then
     cp "$am_scriptdir"/install-sh "$am_scriptdir"/missing \
-       "$am_scriptdir"/depcomp . \
+       "$am_scriptdir"/compile "$am_scriptdir"/depcomp . \
       || framework_failure_ "fetching common files from $am_scriptdir"
     # Build appropriate environment in test directory.  E.g., create
     # configure.ac, touch all necessary files, etc.  Don't use AC_OUTPUT,
diff --git a/t/ccnoco2.sh b/t/ccnoco2.sh
deleted file mode 100755
index a835fa6..0000000
--- a/t/ccnoco2.sh
+++ /dev/null
@@ -1,55 +0,0 @@
-#! /bin/sh
-# Copyright (C) 2006-2013 Free Software Foundation, Inc.
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
-
-# Make sure Automake requires AM_PROG_CC_C_O when either per-targets
-# flags or subdir-objects are used.
-
-. test-init.sh
-
-cat >>configure.ac <<EOF
-AC_PROG_CC
-AC_OUTPUT
-EOF
-
-cat >Makefile.am <<EOF
-bin_PROGRAMS = wish
-wish_SOURCES = a.c
-wish_CPPFLAGS = -DWHATEVER
-EOF
-
-touch a.c
-
-$ACLOCAL
-$AUTOCONF
-AUTOMAKE_fails --copy --add-missing
-grep '^Makefile\.am:2:.*per-target.*AM_PROG_CC_C_O' stderr
-
-
-cat >Makefile.am <<EOF
-bin_PROGRAMS = wish
-wish_SOURCES = sub/a.c
-EOF
-
-mkdir sub
-mv a.c sub
-
-$AUTOMAKE --copy --add-missing
-
-echo 'AUTOMAKE_OPTIONS = subdir-objects' >> Makefile.am
-AUTOMAKE_fails --copy --add-missing
-grep '^Makefile\.am:2:.*subdir.*AM_PROG_CC_C_O' stderr
-
-:
diff --git a/t/cond11.sh b/t/cond11.sh
index 03c4077..7d729d8 100755
--- a/t/cond11.sh
+++ b/t/cond11.sh
@@ -47,7 +47,6 @@ END

 : > config.guess
 : > config.sub
-: > compile

 $ACLOCAL
 $AUTOCONF
diff --git a/t/cxx-lt-demo.sh b/t/cxx-lt-demo.sh
index 8afc974..3a87cfd 100755
--- a/t/cxx-lt-demo.sh
+++ b/t/cxx-lt-demo.sh
@@ -94,10 +94,12 @@ $AUTOCONF
 $AUTOMAKE --add-missing --copy

 ls -l . ax # For debugging.
-for f in ltmain.sh depcomp config.guess config.sub; do
+# Ideally, the 'compile' script should not be required by C++ compilers.
+# But alas, LT_INIT seems to invoke AC_PROG_CC anyway, and that brings in
+# that script.
+for f in ltmain.sh depcomp compile config.guess config.sub; do
   test -f ax/$f && test ! -h ax/$f || exit 1
 done
-test ! -e ax/compile # Not required by C++ compilers.

 cat > src/main.cc << 'END'
 #include "libfoo.h++"
diff --git a/t/dist-auxdir-many-subdirs.sh b/t/dist-auxdir-many-subdirs.sh
index d49372a..ec1a964 100755
--- a/t/dist-auxdir-many-subdirs.sh
+++ b/t/dist-auxdir-many-subdirs.sh
@@ -63,6 +63,7 @@ END
   required_files='
     install-sh
     missing
+    compile
     depcomp
     py-compile
     test-driver
diff --git a/t/distcom2.sh b/t/distcom2.sh
index 57154d9..dc0cb4d 100755
--- a/t/distcom2.sh
+++ b/t/distcom2.sh
@@ -44,6 +44,8 @@ $ACLOCAL

 for opt in '' --no-force; do

+  rm -f compile depcomp
+
   $AUTOMAKE $opt --add-missing

   test -f compile
diff --git a/t/dollarvar2.sh b/t/dollarvar2.sh
index 7183743..ef2dd06 100755
--- a/t/dollarvar2.sh
+++ b/t/dollarvar2.sh
@@ -65,27 +65,22 @@ grep 'recursive variable expansion' stderr
 cat >Makefile.am <<'EOF'
 x = 1
 bla = $(foo$(x))
-noinst_PROGRAMS = foo
-foo_CPPFLAGS = -Dwhatever
+oops = $(var-with-dash)
 EOF

-echo AC_PROG_CC >> configure.ac
-
-$ACLOCAL --force
-
 # Can disable both 'portability' and 'portability-recursive' warnings.
 $AUTOMAKE -Wno-portability

 # Disabling 'portability-recursive' warnings should not disable
 # 'portability' warnings.
 AUTOMAKE_fails -Wportability -Wno-portability-recursive
-grep AM_PROG_CC_C_O stderr
+grep 'var-with-dash' stderr
 grep 'recursive variable expansion' stderr && exit 1

 # Enabling 'portability-recursive' warnings should not enable
 # all the 'portability' warning.
 AUTOMAKE_fails -Wno-portability -Wportability-recursive
-grep AM_PROG_CC_C_O stderr && exit 1
+grep 'var-with-dash' stderr && exit 1
 grep 'recursive variable expansion' stderr

 :
diff --git a/t/extra-portability.sh b/t/extra-portability.sh
index 94dd799..1ea23ad 100755
--- a/t/extra-portability.sh
+++ b/t/extra-portability.sh
@@ -62,30 +62,29 @@ $AUTOMAKE -Wall -Wno-portability
 # Now, a setup where also a "simple" portability warning is present.
 #

-# Per-target flags require the use of AM_PROG_CC_C_O in configure.ac.
-echo libfoo_a_CPPFLAGS = -Dwhatever >> Makefile.am
+echo 'var = $(foo--bar)' >> Makefile.am

 # Enabling extra-portability enables portability as well ...
 AUTOMAKE_fails -Wextra-portability
-grep 'requires.*AM_PROG_CC_C_O' stderr
+grep 'foo--bar' stderr
 grep 'requires.*AM_PROG_AR' stderr
 # ... even if it had been previously disabled.
 AUTOMAKE_fails -Wno-portability -Wextra-portability
-grep 'requires.*AM_PROG_CC_C_O' stderr
+grep 'foo--bar' stderr
 grep 'requires.*AM_PROG_AR' stderr

 # Disabling extra-portability leaves portability intact (1).
 AUTOMAKE_fails -Wportability -Wno-extra-portability
-grep 'requires.*AM_PROG_CC_C_O' stderr
+grep 'foo--bar' stderr
 grep 'requires.*AM_PROG_AR' stderr && exit 1
 # Disabling extra-portability leaves portability intact (2).
 AUTOMAKE_fails -Wall -Wno-extra-portability
-grep 'requires.*AM_PROG_CC_C_O' stderr
+grep 'foo--bar' stderr
 grep 'requires.*AM_PROG_AR' stderr && exit 1

 # Enabling portability does not enable extra-portability.
 AUTOMAKE_fails -Wportability
-grep 'requires.*AM_PROG_CC_C_O' stderr
+grep 'foo--bar' stderr
 grep 'requires.*AM_PROG_AR' stderr && exit 1

 # Disabling portability disables extra-portability.
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 63e098d..aac2506 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -30,7 +30,6 @@ t/pm/Version3.pl

 XFAIL_TESTS = \
 t/all.sh \
-t/ccnoco4.sh \
 t/cond17.sh \
 t/gcj6.sh \
 t/override-conditional-2.sh \
@@ -208,7 +207,6 @@ t/canon7.sh \
 t/canon8.sh \
 t/canon-name.sh \
 t/ccnoco.sh \
-t/ccnoco2.sh \
 t/ccnoco3.sh \
 t/ccnoco4.sh \
 t/check.sh \
diff --git a/t/per-target-flags.sh b/t/per-target-flags.sh
index ef19e69..333242f 100755
--- a/t/per-target-flags.sh
+++ b/t/per-target-flags.sh
@@ -55,15 +55,8 @@ cat - libMakefile.am > libMakefile2.am << 'END'
 AUTOMAKE_OPTIONS = no-dependencies
 END

-# Make sure 'compile' is required.
-for m in $makefiles; do
-  AUTOMAKE_fails $m
-  $EGREP " required file.* '(compile|\./compile)'" stderr
-done
-
 makefiles=$(for mkf in $makefiles; do echo $mkf.in; done)

-: > compile
 $AUTOMAKE

 # Sanity check.
diff --git a/t/specflg6.sh b/t/specflg6.sh
index 77d837a..bbc8334 100755
--- a/t/specflg6.sh
+++ b/t/specflg6.sh
@@ -36,8 +36,6 @@ foo_CFLAGS = -DFOO
 foo_SOURCES = foo.c
 END

-: > compile
-
 $ACLOCAL
 $AUTOMAKE

diff --git a/t/subobj.sh b/t/subobj.sh
index 2431184..6e5fd98 100755
--- a/t/subobj.sh
+++ b/t/subobj.sh
@@ -20,6 +20,8 @@

 cat >> configure.ac << 'END'
 AC_PROG_CC
+dnl This should be a no-op now, but still be supported
+dnl without causing warnings.
 AM_PROG_CC_C_O
 END

@@ -30,10 +32,11 @@ wish_SOURCES = generic/a.c generic/b.c
 END

 $ACLOCAL
+rm -f compile
 $AUTOMAKE --add-missing 2>stderr || { cat stderr >&2; exit 1; }
 cat stderr >&2
 # Make sure compile is installed, and that Automake says so.
-grep 'install.*compile' stderr
+grep '^configure\.ac:4:.*install.*compile' stderr
 test -f compile

 grep '^generic/a\.\$(OBJEXT):' Makefile.in
diff --git a/t/subobj4.sh b/t/subobj4.sh
index b1b577d..45d9666 100755
--- a/t/subobj4.sh
+++ b/t/subobj4.sh
@@ -41,7 +41,6 @@ END
 cat > d2/Makefile.am << 'END'
 END

-: > compile
 : > d2/z.c

 $ACLOCAL
-- 
1.8.1.rc3.192.g2d0029e

Message #76 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o"
	is used with losing compilers
Date: Thu, 10 Jan 2013 15:23:15 +0100

On 01/10/2013 02:33 PM, Stefano Lattarini wrote:
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>
> 
> On 01/08/2013 08:27 PM, Stefano Lattarini wrote:
>> On 01/08/2013 04:29 PM, Eric Blake wrote:
>>> On 01/08/2013 08:15 AM, Stefano Lattarini wrote:
>>>> That would be overkill, since AM_PROG_CC_C_O is only required by
>>>> projects doing C compilation.  Also, IIRC, that macro needs to be
>>>> called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked
>>>> before AC_PROG_CC.
>>>
>>> But with m4, you can arrange for AM_INIT_AUTOMAKE to redefine AC_PROG_CC
>>> so that it hooks in a call to AM_PROG_CC_C_O immediately after its
>>> current definition, and thus still preserve desired ordering while
>>> making the burden simpler for the configure.ac author.
>>>
>> This is true, but I'd have preferred to avoid this shenanigans with
>> macro redefinitions if at all possible.  It seems it won't be really
>> possible though (see also my reply to the last message from Nick):
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>
>> :-(
>>
>> [SNIP]
>>
>> So I think your proposal is the way to go, *right for Automake 1.13.2*,
>> since it offers a bug fix for the situation described in
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>
>>
> Done with the patch below.  The AC_PROG_CC redefinition is more of a
> band-aid rather than a "proper" fix (the copy & paste done by the patch
> is admittedly quite horrific), but that is no big deal IMHO, since we
> will backport the features needed by Automake back into Autoconf, and
> Automake 1.14 will just require the later Autoconf anyway, allowing us
> to get rid of that copy & paste.
> 
> In addition, with this change, the 'compile' script will be required
> in *all* projects using C compilation (even if they don't use the
> 'subdir-objects' option); but this should be noticeable only by
> packages not using 'automake --add-missing' (and they should be the
> great majority), and easily fixable by the other packages anyway.
> 
> OK to push to maint?  I'll wait up to a week to push, since I'd really
> like a review on this ...
>
In fact, we don't need to define the 'NO_MINUS_C_MINUS_O' preprocessor symbol,
nor should we use the 'ac_cv_prog_cc_${ac_cc}_c_o' cache variable (that is
owned by the autoconf macro AC_PROG_CC_C_O).  So consider the below squashed
in.  Let me know if you want me to send a fixed complete patch too.

Regards,
  Stefano

-*-*-*-

diff --git a/NEWS b/NEWS
index e87d267..09bfc1e 100644
--- a/NEWS
+++ b/NEWS
@@ -70,7 +70,10 @@ New in 1.13.2:

   - The AM_PROG_CC_C_O is no longer useful, and its use is a no-op
     now.  Future Automake versions might start warning that this
-    macro is obsolete.
+    macro is obsolete.  For better backward-compatibility, this macro
+    still sets a proper 'ac_cv_prog_cc_*_c_o' cache variable, and
+    define the 'NO_MINUS_C_MINUS_O' C preprocessor symbol, but you
+    should really stop relying on that.

 * Obsolescent features:

diff --git a/m4/init.m4 b/m4/init.m4
index db77a96..c5af65c 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -141,9 +141,9 @@ AC_REQUIRE_AUX_FILE([compile])dnl
 dnl FIXME The following abomination is expected to disappear in
 dnl       Automake 1.14.
 AC_MSG_CHECKING([whether $CC understands -c and -o together])
-set dummy $CC; ac_cc=`AS_ECHO(["$[2]"]) | \
-                      sed 's/[[^a-zA-Z0-9_]]/_/g;s/^[[0-9]]/_/'`
-AC_CACHE_VAL([ac_cv_prog_cc_${am_cc}_c_o],
+set dummy $CC; am__cc=`AS_ECHO(["$[2]"]) | \
+                       sed 's/[[^a-zA-Z0-9_]]/_/g;s/^[[0-9]]/_/'`
+AC_CACHE_VAL([am_cv_prog_cc_${am__cc}_c_o],
 [AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
 # Make sure it works both with $CC and with simple cc.
 # We do the test twice because some compilers refuse to overwrite an
@@ -152,13 +152,13 @@ ac_try='$CC -c conftest.$ac_ext -o conftest2.$ac_objext >&AS_MESSAGE_LOG_FD'
 rm -f conftest2.*
 if _AC_DO_VAR(ac_try) && test -f conftest2.$ac_objext
 then
-  eval ac_cv_prog_cc_${ac_cc}_c_o=yes
+  eval am_cv_prog_cc_${am__cc}_c_o=yes
 else
-  eval ac_cv_prog_cc_${ac_cc}_c_o=no
+  eval am_cv_prog_cc_${am__cc}_c_o=no
 fi
 rm -f core conftest*
 ])dnl
-if eval test \"\$ac_cv_prog_cc_${ac_cc}_c_o\" = yes; then
+if eval test \"\$am_cv_prog_cc_${am__cc}_c_o\" = yes; then
   AC_MSG_RESULT([yes])
 else
   AC_MSG_RESULT([no])
@@ -168,8 +168,6 @@ else
   # A longer-term fix would be to have automake use am__CC in this case,
   # and then we could set am__CC="\$(top_srcdir)/compile \$(CC)"
   CC="$am_aux_dir/compile $CC"
-  AC_DEFINE([NO_MINUS_C_MINUS_O], [1],
-            [Define to 1 if your C compiler doesn't accept -c and -o together.])
 fi
 ])

diff --git a/m4/minuso.m4 b/m4/minuso.m4
index 6cb574e..17fa8c9 100644
--- a/m4/minuso.m4
+++ b/m4/minuso.m4
@@ -15,4 +15,11 @@ dnl Make sure AC_PROG_CC is never called again, or it will override our
 dnl setting of CC.
 m4_define([AC_PROG_CC],
           [m4_fatal([AC_PROG_CC cannot be called after AM_PROG_CC_C_O])])
+# For better backward-compatibility.  Users are advised to stop
+# relying on this cache variable and C preprocessor symbol ASAP.
+eval ac_cv_prog_cc_${am__cc}_c_o=\$am_cv_prog_cc_${am__cc}_c_o
+if eval test \"\$ac_cv_prog_cc_${am__cc}_c_o\" != yes; then
+  AC_DEFINE([NO_MINUS_C_MINUS_O], [1],
+            [Define to 1 if your C compiler doesn't accept -c and -o together.])
+fi
 ])

Message #79 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o"
	is used with losing compilers
Date: Fri, 11 Jan 2013 17:30:18 +0100

[Summarizing the relevant points of the past discussion, somewhat]

Eric Blake wrote:
>
> But with m4, you can arrange for AM_INIT_AUTOMAKE to redefine AC_PROG_CC
> so that it hooks in a call to AM_PROG_CC_C_O immediately after its
> current definition, and thus still preserve desired ordering while
> making the burden simpler for the configure.ac author.

I replied:
>
> This is true, but I'd have preferred to avoid this shenanigans with
> macro redefinitions if at all possible.  It seems it won't be really
> possible though (see also my reply to the last message from Nick):
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>
>
> So I think your proposal is the way to go, *right for Automake 1.13.2*,
> since it offers a bug fix for the situation described in
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>

And then went on to implement the patch:
>
> Done with the patch below.  The AC_PROG_CC redefinition is more of a
> band-aid rather than a "proper" fix (the copy & paste done by the patch
> is admittedly quite horrific), but that is no big deal IMHO, since we
> will backport the features needed by Automake back into Autoconf, and
> Automake 1.14 will just require the later Autoconf anyway, allowing us
> to get rid of that copy & paste.
>

Now, Autoconf has been updated to do what we need:
<http://lists.gnu.org/archive/html/autoconf-patches/2013-01/msg00007.html>
The change above has been committed as 'v2.69-63-gce48964'.

So here is a follow-up that removes the horrible hack introduced by
the previous patch.  Since it will require Autoconf 2.70, it is only
meant to be applied to master of course; but sending it early to
elicit reviews cannot hurt, can it? ;-)

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From ea80119488d2cd38ec3c81119c6019a4b6decb89 Mon Sep 17 00:00:00 2001
Message-Id: <ea80119488d2cd38ec3c81119c6019a4b6decb89.1357921799.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Fri, 11 Jan 2013 16:59:07 +0100
Subject: [PATCH] compile: avoid AC_PROG_CC messy rewrite

Instead, only touch up AC_PROG_CC to distribute the 'compile' script and
to rewrite $CC if a losing compiler is detected.  We can do so because
Autoconf 2.70 (which we now requires) has been so kind to implement the
features we need (through a private hook made explicitly available to us),
in commit v2.69-63-gce48964 of 2013-01-11, "AC_PROG_CC: also check whether
$CC supports "-c -o" together":
<http://lists.gnu.org/archive/html/autoconf-patches/2013-01/msg00007.html>

* m4/init.m4 (AC_PROG_CC): Simplify, relying on the Autoconf hook.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 m4/init.m4 | 42 ++++++++----------------------------------
 1 file changed, 8 insertions(+), 34 deletions(-)

diff --git a/m4/init.m4 b/m4/init.m4
index c5af65c..9316c2c 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -126,42 +126,16 @@ m4_define([_AC_COMPILER_EXEEXT],
 m4_defn([_AC_COMPILER_EXEEXT])[m4_provide([_AM_COMPILER_EXEEXT])])

 dnl We have to redefine AC_PROG_CC to allow our compile rules to use
-dnl "-c -o" together also with losing compilers.
-dnl FIXME: Add references to the original discussion and bug report.
-dnl FIXME: Shameless copy & paste from Autoconf internals, since trying to
-dnl        play smart among tangles of AC_REQUIRE, m4_defn, m4_provide and
-dnl        other tricks was proving too difficult, and in the end, likely
-dnl        more brittle too.  And this should anyway be just a temporary
-dnl        band-aid, until Autoconf provides the semantics and/or hooks we
-dnl        need (hint hint, nudge nudge) ...
+dnl "-c -o" together also with losing compilers.  We can do so using
+dnl a private hook Autoconf has made available to us (since version
+dnl 2.70).
 AC_DEFUN([AC_PROG_CC],
+[AC_REQUIRE([AM_AUX_DIR_EXPAND])]dnl
+[AC_REQUIRE_AUX_FILE([compile])]dnl
+[m4_define([_AM_PROG_CC_C_O_HELPME], [1])]dnl Activate the private hook.
+dnl This must *not* be quoted!
 m4_defn([AC_PROG_CC])
-[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
-AC_REQUIRE_AUX_FILE([compile])dnl
-dnl FIXME The following abomination is expected to disappear in
-dnl       Automake 1.14.
-AC_MSG_CHECKING([whether $CC understands -c and -o together])
-set dummy $CC; am__cc=`AS_ECHO(["$[2]"]) | \
-                       sed 's/[[^a-zA-Z0-9_]]/_/g;s/^[[0-9]]/_/'`
-AC_CACHE_VAL([am_cv_prog_cc_${am__cc}_c_o],
-[AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
-# Make sure it works both with $CC and with simple cc.
-# We do the test twice because some compilers refuse to overwrite an
-# existing .o file with -o, though they will create one.
-ac_try='$CC -c conftest.$ac_ext -o conftest2.$ac_objext >&AS_MESSAGE_LOG_FD'
-rm -f conftest2.*
-if _AC_DO_VAR(ac_try) && test -f conftest2.$ac_objext
-then
-  eval am_cv_prog_cc_${am__cc}_c_o=yes
-else
-  eval am_cv_prog_cc_${am__cc}_c_o=no
-fi
-rm -f core conftest*
-])dnl
-if eval test \"\$am_cv_prog_cc_${am__cc}_c_o\" = yes; then
-  AC_MSG_RESULT([yes])
-else
-  AC_MSG_RESULT([no])
+[if eval test \"\$ac_cv_prog_cc_${ac_cc}_c_o\" != yes; then
   # Losing compiler, so wrap it with the 'compile' script.
   # FIXME: It is wrong to rewrite CC.
   # But if we don't then we get into trouble of one sort or another.
-- 
1.8.1.rc3.192.g2d0029e

Message #82 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o"
	is used with losing compilers
Date: Fri, 11 Jan 2013 10:56:15 -0700

[Message part 1 (text/plain, inline)]

On 01/11/2013 09:30 AM, Stefano Lattarini wrote:

> Subject: [PATCH] compile: avoid AC_PROG_CC messy rewrite
> 
> Instead, only touch up AC_PROG_CC to distribute the 'compile' script and
> to rewrite $CC if a losing compiler is detected.  We can do so because
> Autoconf 2.70 (which we now requires) has been so kind to implement the

s/requires/require/

> features we need (through a private hook made explicitly available to us),
> in commit v2.69-63-gce48964 of 2013-01-11, "AC_PROG_CC: also check whether
> $CC supports "-c -o" together":
> <http://lists.gnu.org/archive/html/autoconf-patches/2013-01/msg00007.html>

Looks reasonable.  I still need to spend another weekend on progressing
towards a release of 2.70.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #85 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: [PATCH] compile: use 'compile' script when "-c -o" is used with
	losing compilers
Date: Fri, 11 Jan 2013 11:19:55 -0700

[Message part 1 (text/plain, inline)]

On 01/10/2013 06:33 AM, Stefano Lattarini wrote:
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>
> 

>  @acindex AC_PROG_CC_C_O
> -This is like @code{AC_PROG_CC_C_O}, but it generates its results in
> -the manner required by Automake.  You must use this instead of
> -@code{AC_PROG_CC_C_O} when you need this functionality, that is, when
> -using per-target flags or subdir-objects with C sources.
> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
> +code needs not to use this macro.  It might be deprecated and

s/needs not to/needs not/

> +@emph{retired in future Automake versions}.

As a rule of thumb on when to remove a macro - I would personally like
being able to write a configure script that works on both RHEL 5 (or
CentOS 5) (autoconf 2.59, automake 1.9.6) as well as rawhide (eventually
automake 1.14 and beyond), for as long as RHEL 5 remains a viable
Enterprise-level distro.

While it is fine to deprecate a macro, or even warn that its use is
obsolete, what I _don't_ want is to have to jump through hoops to make
my configure.ac/Makefile.am do conditionals that says if targetting
older automake, use the older form, else use the newer form.  I would
rather that I can just blindly use the older form, ignore the warnings,
and still have things work.

Someday, RHEL 5 will disappear, and/or upgrade to a newer set of
autotools (I've been campaigning for the latter, and so has Jim Meyering
- the build tools are a special beast, and our argument is that even for
a long-term stable platform, newer build tools is in the platform's best
interest); but until that happens, completely breaking back-compat is
not perceived as very nice.

So even if the macro becomes a no-op and/or issues warnings about being
obsolete, don't completely remove it, and don't force a user to delete
their use of the macro (at least, not unless the user has indicated via
AM_INIT_AUTOMAKE that they are willing to require 1.14 as a minimum
automake version for processing their input files).

> +@item AM_PROG_CC_C_O
> +@acindex AM_PROG_CC_C_O
> +@acindex AC_PROG_CC_C_O
> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
> +code needs not to use this macro.  It will be deprecated, and then
> +removed, in future Automake versions.

Again, removed is too harsh; made a no-op and/or made into a warning
(one which can be silenced for people knowingly being portable to older
automake) is nicer.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #88 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o"
	is used with losing compilers
Date: Fri, 11 Jan 2013 19:43:36 +0100

On 01/11/2013 06:56 PM, Eric Blake wrote:
> On 01/11/2013 09:30 AM, Stefano Lattarini wrote:
> 
>> Subject: [PATCH] compile: avoid AC_PROG_CC messy rewrite
>>
>> Instead, only touch up AC_PROG_CC to distribute the 'compile' script and
>> to rewrite $CC if a losing compiler is detected.  We can do so because
>> Autoconf 2.70 (which we now requires) has been so kind to implement the
> 
> s/requires/require/
> 
Well spotted; will fix locally.

>> features we need (through a private hook made explicitly available to us),
>> in commit v2.69-63-gce48964 of 2013-01-11, "AC_PROG_CC: also check whether
>> $CC supports "-c -o" together":
>> <http://lists.gnu.org/archive/html/autoconf-patches/2013-01/msg00007.html>
> 
> Looks reasonable.  I still need to spend another weekend on progressing
> towards a release of 2.70.
>
Thanks, that is truly appreciated.

Best regards,
  Stefano

Message #91 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Backward-compatibility in the autotools (was: Re: [PATCH] compile:
	use 'compile' script when "-c -o" is used with losing compilers)
Date: Fri, 11 Jan 2013 19:45:39 +0100

On 01/11/2013 07:19 PM, Eric Blake wrote:
> On 01/10/2013 06:33 AM, Stefano Lattarini wrote:
>> Reference:
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>
>>
> 
>>  @acindex AC_PROG_CC_C_O
>> -This is like @code{AC_PROG_CC_C_O}, but it generates its results in
>> -the manner required by Automake.  You must use this instead of
>> -@code{AC_PROG_CC_C_O} when you need this functionality, that is, when
>> -using per-target flags or subdir-objects with C sources.
>> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
>> +code needs not to use this macro.  It might be deprecated and
> 
> s/needs not to/needs not/
>
Fixed, thanks.

>> +@emph{retired in future Automake versions}.
> 
> As a rule of thumb on when to remove a macro - I would personally like
> being able to write a configure script that works on both RHEL 5 (or
> CentOS 5) (autoconf 2.59, automake 1.9.6) as well as rawhide (eventually
> automake 1.14 and beyond), for as long as RHEL 5 remains a viable
> Enterprise-level distro.
>
I'm quite unconvinced of the value in trying to support this.  Developers
should just keep their tool reasonably up-to date IMHO; if they can't
do so through their package manager, they should do so by installing
from source.  And while I see this can be a problem for complex packages
like Perl [1] or GCC, it is easily done for package simpler to install,
like the autotools are.

 [1] I try to keep support for older Perl versions alive in Automake
     exactly because I've seen which pain is to correctly install Perl
     from sources.

> While it is fine to deprecate a macro, or even warn that its use is
> obsolete, what I _don't_ want is to have to jump through hoops to make
> my configure.ac/Makefile.am do conditionals that says if targetting
> older automake, use the older form, else use the newer form.  I would
> rather that I can just blindly use the older form, ignore the warnings,
> and still have things work.
>
For a while, this is ok.  In fact, I plan to have AM_PROG_CC_C_O start
issue warnings only in Automake 1.14, and be removed not before Automake
1.16.  But trying to keep a package working with Automake versions that
are six, seven years apart (as 1.9.6 and 1.13 are) is asking for trouble,
and not worth fighting too hard to support.

Also, in this case (as in the case for AM_PROG_MKDIR_P), a user still
wanting to use use the obsolete macro can simply define it in, say,
acinclude.m4.

> Someday, RHEL 5 will disappear, and/or upgrade to a newer set of
> autotools (I've been campaigning for the latter, and so has Jim Meyering
> - the build tools are a special beast, and our argument is that even for
> a long-term stable platform, newer build tools is in the platform's best
> interest); but until that happens, completely breaking back-compat is
> not perceived as very nice.
> 
> So even if the macro becomes a no-op
>
Which is as of today, but that is OK, since it does no harm to the users
nor the code base.

> and/or issues warnings about being obsolete,
>
This for sure won't happen before Automake 1.14.

> don't completely remove it, and don't force a user to delete
> their use of the macro (at least, not unless the user has indicated via
> AM_INIT_AUTOMAKE that they are willing to require 1.14 as a minimum
> automake version for processing their input files).
>
As for this, there is no hurry.

>> +@item AM_PROG_CC_C_O
>> +@acindex AM_PROG_CC_C_O
>> +@acindex AC_PROG_CC_C_O
>> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
>> +code needs not to use this macro.  It will be deprecated, and then
>> +removed, in future Automake versions.
> 
> Again, removed is too harsh;
>
I believe it is necessary to really inform the users about upcoming
obsolescence, lest they got unwittingly bitten by the eventual deprecation
or removal.  So I'd really like to keep this harsh wording in place.  (Of
course, the macro will not be removed without having spent at least a major
release cycle as deprecated at runtime; having done a huge screw-up in that
regard has been enough for me).

> made a no-op and/or made into a warning
> (one which can be silenced for people knowingly being portable to older
> automake) is nicer.
> 
Which is why we will follow this road in the next two major releases.
But again, IMHO, that's is not a good reason not to warn users.

Regards,
  Stefano

Message #94 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o"
	is used with losing compilers
Date: Fri, 11 Jan 2013 20:16:05 +0100

On 01/11/2013 07:19 PM, Eric Blake wrote:
> On 01/10/2013 06:33 AM, Stefano Lattarini wrote:
>> Reference:
>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>
>>
> 
>>  @acindex AC_PROG_CC_C_O
>> -This is like @code{AC_PROG_CC_C_O}, but it generates its results in
>> -the manner required by Automake.  You must use this instead of
>> -@code{AC_PROG_CC_C_O} when you need this functionality, that is, when
>> -using per-target flags or subdir-objects with C sources.
>> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
>> +code needs not to use this macro.  It might be deprecated and
> 
> s/needs not to/needs not/
> 
Fixed, thanks.  I will soon merge the patch into maint.  As for your
objections to the wording used in some of the documentation changes
(snipped here, to which I have replied in another mail), they can be
worked out further on-list, and if a consensus is reached, we can
adjust the documentation with follow-up patches without problem.

Thanks,
  Stefano

Message #97 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o"
	is used with losing compilers
Date: Sat, 12 Jan 2013 11:05:30 +0100

On 01/11/2013 08:16 PM, Stefano Lattarini wrote:
> On 01/11/2013 07:19 PM, Eric Blake wrote:
>> On 01/10/2013 06:33 AM, Stefano Lattarini wrote:
>>> Reference:
>>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>
>>>
>>
>>>  @acindex AC_PROG_CC_C_O
>>> -This is like @code{AC_PROG_CC_C_O}, but it generates its results in
>>> -the manner required by Automake.  You must use this instead of
>>> -@code{AC_PROG_CC_C_O} when you need this functionality, that is, when
>>> -using per-target flags or subdir-objects with C sources.
>>> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
>>> +code needs not to use this macro.  It might be deprecated and
>>
>> s/needs not to/needs not/
>>
> Fixed, thanks.  I will soon merge the patch into maint.
>
Done.  Also merged maint into master, and pushed.

Thanks,
  Stefano

Message #100 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake-patches <at> gnu.org
Cc: 13378 <at> debbugs.gnu.org
Subject: [FYI] {maint} coverage: obsolete macro AM_PROG_CC_C_O should cause no
	warning nor errors
Date: Sat, 12 Jan 2013 12:33:22 +0100

Suggested by Eric Blake.

* t/am-prog-cc-c-o.sh: New test.
* t/list-of-tests.mk: Add it.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 t/am-prog-cc-c-o.sh | 85 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 t/list-of-tests.mk  |  1 +
 2 files changed, 86 insertions(+)
 create mode 100755 t/am-prog-cc-c-o.sh

diff --git a/t/am-prog-cc-c-o.sh b/t/am-prog-cc-c-o.sh
new file mode 100755
index 0000000..f9cc04a
--- /dev/null
+++ b/t/am-prog-cc-c-o.sh
@@ -0,0 +1,85 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Check that uses of the obsolescent AM_PROG_CC_C_O macro doesn't
+# cause spurious warnings or errors.  Suggested by Eric Blake.
+
+# We need gcc for for two reasons:
+#  1. to ensure our C compiler grasps "-c -o" together.
+#  2. to be able to later fake a dumb compiler not grasping that
+#     (done with 'cc-no-c-o' script below, which required gcc).
+required=gcc
+. test-init.sh
+
+echo bin_PROGRAMS = foo > Makefile.am
+echo 'int main (void) { return 0; }' > foo.c
+
+cp configure.ac configure.bak
+
+cat >> configure.ac << 'END'
+# Since AM_PROG_CC_C_O rewrites $CC, it's an error to call AC_PROG_CC
+# after it.
+AM_PROG_CC_C_O
+AC_PROG_CC
+END
+
+$ACLOCAL -Wnone 2>stderr && { cat stderr >&2; exit 1; }
+cat stderr >&2
+grep '^configure\.ac:7:.* AC_PROG_CC .*called after AM_PROG_CC_C_O' stderr
+
+cat configure.bak - > configure.ac << 'END'
+dnl It's OK to call AM_PROG_CC_C_O after AC_PROG_CC.
+AC_PROG_CC
+AM_PROG_CC_C_O
+AC_OUTPUT
+END
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing
+
+./configure >stdout || { cat stdout; exit 1; }
+cat stdout
+grep 'understands -c and -o together.* yes$' stdout
+# No repeated checks please.
+test $(grep -c ".*-c['\" ].*-o['\" ]" stdout) -eq 1
+$MAKE
+
+$MAKE maintainer-clean
+
+rm -rf autom4te*.cache
+
+cat configure.bak - > configure.ac << 'END'
+dnl It's also OK to call AM_PROG_CC_C_O *without* AC_PROG_CC.
+AM_PROG_CC_C_O
+AC_OUTPUT
+END
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing
+
+# Make sure the compiler doesn't understand '-c -o'
+CC=$am_testaux_builddir/cc-no-c-o; export CC
+
+./configure >stdout || { cat stdout; exit 1; }
+cat stdout
+grep 'understands -c and -o together.* no$' stdout
+# No repeated checks please.
+test $(grep -c ".*-c['\" ].*-o['\" ]" stdout) -eq 1
+$MAKE
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index baccdca..a6e1cee 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -132,6 +132,7 @@ t/aminit-moreargs-deprecation.sh \
 t/amassign.sh \
 t/am-config-header-no-more.sh \
 t/am-prog-cc-stdc-no-more.sh \
+t/am-prog-cc-c-o.sh \
 t/am-macro-not-found.sh \
 t/amopt.sh \
 t/amopts-location.sh \
-- 
1.8.1.rc3.192.g2d0029e

Message #103 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 13378 <at> debbugs.gnu.org
Subject: Patches for master, making 'subdir-objects' mandatory
Date: Sat, 12 Jan 2013 14:25:28 +0100

I thought I had managed to send the cover letter of that patch
series to the bug tracker too, but I was wrong.  Oh well.  Here
is the link:

  http://lists.gnu.org/archive/html/automake-patches/2013-01/msg00102.html

Stefano

Message #106 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 13378 <at> debbugs.gnu.org
Cc: "automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: [PATCH] subdir-objects: complain if it isn't enabled (was: Re:
	bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the default,
	and only available one)
Date: Sun, 13 Jan 2013 20:51:33 +0100

Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378>

On 01/07/2013 09:08 PM, Stefano Lattarini wrote:
> Severity: wishlist
> 
> Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07,
> "[ng] subdir-objects: enable unconditionally".
> 
> The fact that Automake-generated Makefiles place compiled object files in
> he current directory by default, also when the corresponding source file
> is in a subdirectory, is basically an historical accident, due to the fact
> that the 'subdir-objects' option had only been introduced in April 1999,
> starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never
> made the default (likely to avoid backwards-compatibility issues).
> 
> Since I believe the behaviour enabled by the 'subdir-objects' is the most
> useful one, and in fact the *only* natural one, I'd like to make it the
> the only one available, simplifying the Automake implementation and APIs
> a little in the process.
> 
> Alas, since this also means changing the default behaviour of Automake
> ('subdir-objects' is not enabled by default, sadly), this means the
> transition path will be less smooth than I'd like.  Here it is a sketch
> for it:
> 
>   Automake 1.13.2
>   ---------------
> 
>   Give a warning in the category 'unsupported' if the 'subdir-objects'
>   option is not specified.  This should give the users enough forewarning
>   about the planned change, and give them time to update their packages
>   to the new semantic.
> 
Here is a patch doing that.  I will push it in a couple of days if there
are no objections.

Regards,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From 4864af66bfd189a501061d775bb9743a1285d88e Mon Sep 17 00:00:00 2001
Message-Id: <4864af66bfd189a501061d775bb9743a1285d88e.1358106576.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Sun, 13 Jan 2013 17:50:30 +0100
Subject: [PATCH] subdir-objects: complain if it isn't enabled

Since the next major automake version will make the behaviour so far
only activated with the 'subdir-object' option mandatory, it's better
if we start warning users not using that option.

As suggested by Peter Johansson, we strive to avoid the warning when
it would be irrelevant, i.e., if all source files sit in "current"
directory.

See automake bug#13378.

* automake.in (handle_single_transform): Print the warning when
necessary.
* t/subobj.sh: Enhance.
* t/ax/depcomp.sh: Adjust.
* t/cscope.tap: Likewise.
* t/depcomp8a.sh: Likewise.
* t/depcomp8b.sh: Likewise.
* t/ext2.sh: Likewise.
* t/extra-portability.sh: Likewise.
* t/fort2.sh: Likewise.
* t/fort4.sh: Likewise.
* t/fort5.sh: Likewise.
* t/lex-line.sh: Likewise.
* t/libtool3.sh: Likewise.
* t/ltinstloc.sh: Likewise.
* t/ltlibsrc.sh: Likewise.
* t/ltorder.sh: Likewise.
* t/parallel-tests-suffix-prog.sh: Likewise.
* t/sourcefile-in-subdir.sh: Likewise.
* t/specflg9.sh: Likewise.
* t/subobj4.sh: Likewise.
* t/subobj7.sh: Likewise.
* t/subpkg-yacc.sh: Likewise.
* t/subpkg.sh: Likewise.
* t/suffix-custom-subobj-and-specflg.sh: Likewise.
* t/vala-libs.sh: Likewise.
* t/vala-non-recursive-setup.sh: Likewise.
* t/yacc-grepping2.sh: Likewise.
* t/yacc-line.sh: Likewise.
---
 automake.in                           | 31 ++++++++++++++++--
 t/ax/depcomp.sh                       |  9 +++---
 t/cscope.tap                          |  6 ++--
 t/depcomp8a.sh                        |  4 ++-
 t/depcomp8b.sh                        |  9 ++++--
 t/ext2.sh                             |  1 +
 t/extra-portability.sh                |  2 +-
 t/fort2.sh                            | 58 +++++++++++++++++++++++++--------
 t/fort4.sh                            |  2 +-
 t/fort5.sh                            |  4 ++-
 t/lex-line.sh                         |  4 ++-
 t/libtool3.sh                         |  4 +++
 t/ltinstloc.sh                        |  1 +
 t/ltlibsrc.sh                         |  2 ++
 t/ltorder.sh                          |  1 +
 t/parallel-tests-suffix-prog.sh       |  1 +
 t/sourcefile-in-subdir.sh             |  2 +-
 t/specflg9.sh                         |  1 +
 t/subobj.sh                           | 61 +++++++++++++++++++++++++++++++----
 t/subobj4.sh                          |  2 +-
 t/subobj7.sh                          |  1 +
 t/subpkg-yacc.sh                      |  2 +-
 t/subpkg.sh                           |  2 +-
 t/suffix-custom-subobj-and-specflg.sh | 11 +------
 t/vala-libs.sh                        |  3 +-
 t/vala-non-recursive-setup.sh         |  1 +
 t/yacc-grepping2.sh                   | 10 +++---
 t/yacc-line.sh                        |  4 ++-
 28 files changed, 183 insertions(+), 56 deletions(-)

diff --git a/automake.in b/automake.in
index 990b60d..0e3b882 100644
--- a/automake.in
+++ b/automake.in
@@ -1793,9 +1793,36 @@ sub handle_single_transform ($$$$$%)

 	    # If rewrite said it was ok, put the object into a
 	    # subdir.
-	    if ($r == LANG_SUBDIR && $directory ne '')
+	    if ($directory ne '')
 	    {
-		$object = $directory . '/' . $object;
+              if ($r == LANG_SUBDIR)
+                {
+                  $object = $directory . '/' . $object;
+                }
+              else
+                {
+                  # Since the next major version of automake (1.14) will
+                  # make the behaviour so far only activated with the
+                  # 'subdir-object' option mandatory, it's better if we
+                  # start warning users not using that option.
+                  # As suggested by Peter Johansson, we strive to avoid
+                  # the warning when it would be irrelevant, i.e., if
+                  # all source files sit in "current" directory.
+                  msg_var 'unsupported', $var,
+                          "source file '$full' is in a subdirectory,"
+                          . "\nbut option 'subdir-objects' is disabled";
+                  msg 'unsupported', INTERNAL, <<'EOF', uniq_scope => US_GLOBAL;
+possible forward-incompatibility.
+At least a source file is in a subdirectory, but the 'subdir-objects'
+automake option hasn't been enabled.  For now, the corresponding output
+object file(s) will be placed in the top-level directory.  However,
+this behaviour will change in future Automake versions: they will
+unconditionally cause object files to be placed in the same subdirectory
+of the corresponding sources.
+You are advised to start using 'subdir-objects' option throughout your
+project, to avoid future incompatibilities.
+EOF
+                }
 	    }

 	    # If the object file has been renamed (because per-target
diff --git a/t/ax/depcomp.sh b/t/ax/depcomp.sh
index 0e5b6a5..1534d5f 100644
--- a/t/ax/depcomp.sh
+++ b/t/ax/depcomp.sh
@@ -130,7 +130,7 @@ check_distclean ()
 cat > configure.ac <<END
 AC_INIT([$me], [1.0])
 AC_CONFIG_AUX_DIR([build-aux])
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([subdir-objects])
 AC_PROG_CC
 AM_PROG_AR
 $(if test $depcomp_with_libtool = yes; then
@@ -199,18 +199,17 @@ ${normalized_target}_${LINKADD} = src/libbaz.$a
 grep-test:
 ## For debugging.
 	cat \$(DEPDIR)/foo.$po || :
-	cat \$(DEPDIR)/subfoo.$po || :
+	cat sub/\$(DEPDIR)/subfoo.$po || :
 	cat src/\$(DEPDIR)/baz.$po || :
 	cat src/sub2/\$(DEPDIR)/sub2foo.$po || :
-## Checks done here.
+## Checks are done here.
 	grep '^foo.$objext.*:' \$(DEPDIR)/foo.$po
-	grep '^subfoo\.$objext.*:' \$(DEPDIR)/subfoo.$po
+	grep '^sub/subfoo\.$objext.*:' sub/\$(DEPDIR)/subfoo.$po
 	grep '^baz\.$objext.*:' src/\$(DEPDIR)/baz.$po
 	grep '^sub2/sub2foo\.$objext.*:' src/sub2/\$(DEPDIR)/sub2foo.$po
 END

 cat > src/Makefile.am <<END
-AUTOMAKE_OPTIONS = subdir-objects
 noinst_${LIBPRIMARY} = libbaz.$a
 # We include sub2foo only to be sure that the munging in depcomp
 # doesn't remove too much from the object file name.
diff --git a/t/cscope.tap b/t/cscope.tap
index 29feec2..9dbe01b 100755
--- a/t/cscope.tap
+++ b/t/cscope.tap
@@ -22,8 +22,10 @@ plan_ 18

 ocwd=$(pwd) || fatal_ "getting top-level directory"

-cat >> configure.ac << 'END'
-AC_CONFIG_FILES([sub/Makefile])
+cat > configure.ac << 'END'
+AC_INIT([cscope-test], [1.0])
+AM_INIT_AUTOMAKE([subdir-objects])
+AC_CONFIG_FILES([Makefile sub/Makefile])
 AC_SUBST([CC],  [who-cares])
 AC_SUBST([CXX], [who-cares])
 AC_SUBST([FC],  [who-cares])
diff --git a/t/depcomp8a.sh b/t/depcomp8a.sh
index 76aa376..d6c73ed 100755
--- a/t/depcomp8a.sh
+++ b/t/depcomp8a.sh
@@ -48,7 +48,9 @@ int bar (void)
 END

 $ACLOCAL
-$AUTOMAKE -a
+# FIXME: stop disabling the warnings in the 'unsupported' category
+# FIXME: once the 'subdir-objects' option has been mandatory.
+$AUTOMAKE -a -Wno-unsupported
 grep include Makefile.in # For debugging.
 grep 'include.*\./\$(DEPDIR)/foo\.P' Makefile.in
 grep 'include.*\./\$(DEPDIR)/bar\.P' Makefile.in
diff --git a/t/depcomp8b.sh b/t/depcomp8b.sh
index 52382f1..879ee1c 100755
--- a/t/depcomp8b.sh
+++ b/t/depcomp8b.sh
@@ -31,6 +31,9 @@ AC_OUTPUT
 END

 cat > Makefile.am << 'END'
+## FIXME: stop disabling the warnings in the 'unsupported' category
+## FIXME: once the 'subdir-objects' option has been mandatory.
+AUTOMAKE_OPTIONS = -Wno-unsupported
 lib_LTLIBRARIES = libzardoz.la
 libzardoz_la_SOURCES = foo.c sub/bar.c
 END
@@ -42,7 +45,9 @@ echo 'int bar (void) { return 0; }' > sub/bar.c
 libtoolize

 $ACLOCAL
-$AUTOMAKE -a
+# FIXME: stop disabling the warnings in the 'unsupported' category
+# FIXME: once the 'subdir-objects' option has been mandatory.
+$AUTOMAKE -a -Wno-unsupported
 grep include Makefile.in # For debugging.
 grep 'include.*\./\$(DEPDIR)/foo\.P' Makefile.in
 grep 'include.*\./\$(DEPDIR)/bar\.P' Makefile.in
@@ -56,7 +61,7 @@ DISTCHECK_CONFIGURE_FLAGS='--enable-dependency-tracking' $MAKE distcheck

 # Try again with subdir-objects option.

-echo AUTOMAKE_OPTIONS = subdir-objects >> Makefile.am
+echo AUTOMAKE_OPTIONS += subdir-objects >> Makefile.am

 $AUTOMAKE
 grep include Makefile.in # For debugging.
diff --git a/t/ext2.sh b/t/ext2.sh
index 1089080..4858aec 100755
--- a/t/ext2.sh
+++ b/t/ext2.sh
@@ -25,6 +25,7 @@ AC_PROG_CXX
 EOF

 cat >Makefile.am <<EOF
+AUTOMAKE_OPTIONS = subdir-objects
 bin_PROGRAMS = p q r
 p_SOURCES = a.cc b.cpp c.cxx
 q_SOURCES = sub/d.cc sub/e.cpp sub/f.cxx
diff --git a/t/extra-portability.sh b/t/extra-portability.sh
index 1ea23ad..63849c7 100755
--- a/t/extra-portability.sh
+++ b/t/extra-portability.sh
@@ -40,7 +40,7 @@ $ACLOCAL

 cat >Makefile.am <<END
 EXTRA_LIBRARIES = libfoo.a
-libfoo_a_SOURCES = sub/foo.c
+libfoo_a_SOURCES = foo.c
 END

 # Sanity check: extra-portability warnings causes the expected error.
diff --git a/t/fort2.sh b/t/fort2.sh
index c99e8b7..d614452 100755
--- a/t/fort2.sh
+++ b/t/fort2.sh
@@ -19,6 +19,7 @@

 # Cf. 'fort1.sh' and 'link_f90_only.sh'.

+required=gfortran # Required only in order to run ./configure.
 . test-init.sh

 mkdir sub
@@ -30,33 +31,64 @@ AC_FC_SRCEXT([f95])
 AC_FC_SRCEXT([f03])
 AC_FC_SRCEXT([f08])
 AC_FC_SRCEXT([blabla])
+AC_OUTPUT
 END

 cat >Makefile.am <<'END'
+AUTOMAKE_OPTIONS = subdir-objects
+FC = fake-fc
 bin_PROGRAMS = hello goodbye
-hello_SOURCES = hello.f90 foo.f95 sub/bar.f95 hi.f03 sub/howdy.f03 greets.f08 sub/bonjour.f08
+hello_SOURCES = hello.f90 foo.f95 sub/bar.f95 hi.f03 sub/howdy.f03 \
+                greets.f08 sub/bonjour.f08
 goodbye_SOURCES = bye.f95 sub/baz.f90
-goodbye_FCFLAGS =
+goodbye_FCFLAGS = --gby
 END

 $ACLOCAL
 $AUTOMAKE
-# The following tests aren't fool-proof, but they don't
-# need a Fortran compiler.
 grep '.\$(LINK)'       Makefile.in && exit 1
 grep '.\$(FCLINK)'     Makefile.in
 grep '.\$(FCCOMPILE)'  Makefile.in > stdout
 cat stdout
 grep -v '\$(FCFLAGS_f' stdout && exit 1
 grep '.\$(FC.*\$(FCFLAGS_blabla' Makefile.in && exit 1
-# Notice the TAB:
-grep '^[	].*\$(FC.*\$(FCFLAGS_f90).*\.f90' Makefile.in
-grep '^[	].*\$(FC.*\$(FCFLAGS_f95).*\.f95' Makefile.in
-grep '^[	].*\$(FC.*\$(FCFLAGS_f03).*\.f03' Makefile.in
-grep '^[	].*\$(FC.*\$(FCFLAGS_f08).*\.f08' Makefile.in
-grep '^[	].*\$(FC.*\$(FCFLAGS_f90).*\.f95' Makefile.in && exit 1
-grep '^[	].*\$(FC.*\$(FCFLAGS_f95).*\.f90' Makefile.in && exit 1
-grep '^[	].*\$(FC.*\$(FCFLAGS_f90).*\.f03' Makefile.in && exit 1
-grep '^[	].*\$(FC.*\$(FCFLAGS_f08).*\.f90' Makefile.in && exit 1
+
+sed '/^AC_FC_SRCEXT.*blabla/d' configure.ac >t
+mv -f t configure.ac
+
+rm -rf autom4te*.cache
+$ACLOCAL
+$AUTOMAKE
+$AUTOCONF
+
+./configure
+
+touch hello.f90 foo.f95 sub/bar.f95 hi.f03 sub/howdy.f03 greets.f08 \
+      sub/bonjour.f08 bye.f95 sub/baz.f90
+
+$MAKE -n \
+  FCFLAGS_f90=--@90 FCFLAGS_f95=--@95 FCFLAGS_f03=--@03 FCFLAGS_f08=--@08 \
+  > stdout || { cat stdout; exit 1; }
+cat stdout
+# To make it easier to have  stricter grepping below.
+sed -e 's/[ 	][ 	]*/  /g' -e 's/^/ /' -e 's/$/ /' stdout > out
+cat out
+
+grep ' fake-fc .* --@90 .* hello\.f90 ' out
+grep ' fake-fc .* --@95 .* foo\.f95 ' out
+grep ' fake-fc .* --@95 .* sub/bar\.f95 ' out
+grep ' fake-fc .* --@03 .* hi\.f03 ' out
+grep ' fake-fc .* --@03 .* sub/howdy\.f03 ' out
+grep ' fake-fc .* --@08 .* greets\.f08 ' out
+grep ' fake-fc .* --@08 .* sub/bonjour\.f08 ' out
+grep ' fake-fc .* --gby .* --@95 .*[` ]bye\.f95 ' out
+grep ' fake-fc .* --gby .* --@90 .*[` ]sub/baz\.f90 ' out
+
+test $(grep -c '.*--gby.*\.f' out) -eq 2
+
+$EGREP 'fake-fc.*--@(95|03|08).*\.f90' out && exit 1
+$EGREP 'fake-fc.*--@(90|03|08).*\.f95' out && exit 1
+$EGREP 'fake-fc.*--@(90|95|08).*\.f03' out && exit 1
+$EGREP 'fake-fc.*--@(95|95|03).*\.f08' out && exit 1

 :
diff --git a/t/fort4.sh b/t/fort4.sh
index 822edb8..2ef27ab 100755
--- a/t/fort4.sh
+++ b/t/fort4.sh
@@ -65,7 +65,7 @@ LDADD = $(FCLIBS)
 END

 $ACLOCAL
-$AUTOMAKE -a
+$AUTOMAKE -a -Wno-unsupported
 # The Fortran 77 linker should be preferred:
 grep '.\$(FCLINK)' Makefile.in && exit 1

diff --git a/t/fort5.sh b/t/fort5.sh
index 0272706..7b9991b 100755
--- a/t/fort5.sh
+++ b/t/fort5.sh
@@ -75,7 +75,9 @@ END

 libtoolize --force
 $ACLOCAL
-$AUTOMAKE -a
+# FIXME: stop disabling the warnings in the 'unsupported' category
+# FIXME: once the 'subdir-objects' option has been mandatory.
+$AUTOMAKE -a -Wno-unsupported
 $AUTOCONF

 # This test requires Libtool >= 2.0.  Earlier Libtool does not
diff --git a/t/lex-line.sh b/t/lex-line.sh
index 9b27c0b..258f6af 100755
--- a/t/lex-line.sh
+++ b/t/lex-line.sh
@@ -86,7 +86,9 @@ c_outputs='zardoz.c bar-quux.c sub/foo-zardoz.c sub/dir/quux.c'

 $ACLOCAL
 $AUTOCONF
-$AUTOMAKE -a
+# FIXME: stop disabling the warnings in the 'unsupported' category
+# FIXME: once the 'subdir-objects' option has been mandatory.
+$AUTOMAKE -a -Wno-unsupported

 for vpath in : false; do

diff --git a/t/libtool3.sh b/t/libtool3.sh
index fb8c194..5653280 100755
--- a/t/libtool3.sh
+++ b/t/libtool3.sh
@@ -28,6 +28,10 @@ AC_OUTPUT
 END

 cat > Makefile.am << 'END'
+# FIXME: stop disabling the warnings in the 'unsupported' category
+# FIXME: once the 'subdir-objects' option has been mandatory.
+AUTOMAKE_OPTIONS = -Wno-unsupported
+
 lib_LTLIBRARIES = lib0.la liba/liba.la
 lib0_la_SOURCES = 0.c
 liba_liba_la_SOURCES = liba/a.c
diff --git a/t/ltinstloc.sh b/t/ltinstloc.sh
index b9670cb..bae3d49 100755
--- a/t/ltinstloc.sh
+++ b/t/ltinstloc.sh
@@ -35,6 +35,7 @@ lib_LTLIBRARIES = liba1.la sub/liba2.la
 pkglib_LTLIBRARIES = liba1.la
 nobase_lib_LTLIBRARIES = sub/liba2.la
 endif
+AUTOMAKE_OPTIONS = subdir-objects
 END

 libtoolize
diff --git a/t/ltlibsrc.sh b/t/ltlibsrc.sh
index e58bba7..8c8098b 100755
--- a/t/ltlibsrc.sh
+++ b/t/ltlibsrc.sh
@@ -35,6 +35,8 @@ noinst_LTLIBRARIES = foo.la zoo.d/old2.la

 $(srcdir)/zoo_d_old2_la.c: $(srcdir)/old_la.c
 	cp $(srcdir)/old_la.c $@
+
+AUTOMAKE_OPTIONS = -Wno-unsupported
 END

 cat > foo.c << 'END'
diff --git a/t/ltorder.sh b/t/ltorder.sh
index fe9d7bd..c243ac7 100755
--- a/t/ltorder.sh
+++ b/t/ltorder.sh
@@ -27,6 +27,7 @@ AC_OUTPUT
 END

 cat >Makefile.am <<'END'
+AUTOMAKE_OPTIONS = subdir-objects
 nobase_lib_LTLIBRARIES = liba1.la sub/liba2.la sub/liba3.la liba4.la liba5.la
 sub_liba2_la_LIBADD = liba1.la
 sub_liba3_la_LIBADD = sub/liba2.la
diff --git a/t/parallel-tests-suffix-prog.sh b/t/parallel-tests-suffix-prog.sh
index 64f103c..7b924a3 100755
--- a/t/parallel-tests-suffix-prog.sh
+++ b/t/parallel-tests-suffix-prog.sh
@@ -27,6 +27,7 @@ AC_OUTPUT
 END

 cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
 ## Note that automake should not match the '/test' part of 'sub/test' as
 ## '.test' suffix, nor the '/chk' part of 'sub/chk' as '.chk' suffix.
 TESTS = $(dist_TESTS) $(check_PROGRAMS)
diff --git a/t/sourcefile-in-subdir.sh b/t/sourcefile-in-subdir.sh
index a010776..1054f18 100755
--- a/t/sourcefile-in-subdir.sh
+++ b/t/sourcefile-in-subdir.sh
@@ -29,7 +29,7 @@ AC_PROG_CC
 END

 $ACLOCAL
-$AUTOMAKE
+$AUTOMAKE -Wno-unsupported

 grep '^z\.o: x/z\.c$' Makefile.in

diff --git a/t/specflg9.sh b/t/specflg9.sh
index 3e0c694..4f3d3b0 100755
--- a/t/specflg9.sh
+++ b/t/specflg9.sh
@@ -24,6 +24,7 @@ AC_OUTPUT
 END

 cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
 bin_PROGRAMS = zzfoo zzbar
 zzfoo_SOURCES = sub/foo.c
 zzbar_SOURCES = bar.c
diff --git a/t/subobj.sh b/t/subobj.sh
index d16512a..22ab2d3 100755
--- a/t/subobj.sh
+++ b/t/subobj.sh
@@ -14,19 +14,63 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.

-# Test of subdir objects with C.
+# Test of subdir objects with C and C++.

 . test-init.sh

-echo AC_PROG_CC >> configure.ac
+cat >> configure.ac <<'END'
+AC_PROG_CC
+AC_PROG_CXX
+AC_PROG_YACC
+AC_CONFIG_FILES([sub/Makefile])
+END
+
+$ACLOCAL
+: > ylwrap

 cat > Makefile.am << 'END'
-AUTOMAKE_OPTIONS = subdir-objects
+SUBDIRS = sub
 bin_PROGRAMS = wish
-wish_SOURCES = generic/a.c generic/b.c
+wish_SOURCES = generic/a.c
+wish_SOURCES += another/z.cxx
 END

-$ACLOCAL
+mkdir sub
+cat > sub/Makefile.am << 'END'
+dream_SOURCES = generic/b.c more/r.y
+bin_PROGRAMS = dream
+END
+
+AUTOMAKE_fails
+grep "^Makefile\.am:3:.*'generic/a\.c'.* in a subdirectory" stderr
+grep "^Makefile\.am:[34]:.*'another/z\.cxx'.* in a subdirectory" stderr
+grep "^sub/Makefile\.am:1:.*'generic/b\.c'.* in a subdirectory" stderr
+grep "option 'subdir-objects' is disabled" stderr
+# Verbose tips should be given, but not too many times.
+for msg in \
+  "possible forward-incompatibility" \
+  "advi[sc]e.* 'subdir-objects' option throughout" \
+  "unconditionally.* object file.* same subdirectory" \
+; do
+  test $(grep -c "$msg" stderr) -eq 1
+done
+
+# Guard against stupid typos.
+grep 'subdir-object([^s]|$)' stderr && exit 1
+
+$AUTOMAKE -Wno-unsupported
+
+echo AUTOMAKE_OPTIONS = subdir-objects >> Makefile.am
+AUTOMAKE_fails
+grep "^Makefile\.am" stderr && exit 1
+grep "^sub/Makefile\.am:.*'generic/b\.c'.* in a subdirectory" stderr
+grep "option 'subdir-objects' is disabled" stderr
+
+sed 's/^AM_INIT_AUTOMAKE/&([subdir-objects])/' configure.ac > configure.tmp
+mv -f configure.tmp configure.ac
+$ACLOCAL --force
+$AUTOMAKE
+
 rm -f compile
 $AUTOMAKE --add-missing 2>stderr || { cat stderr >&2; exit 1; }
 cat stderr >&2
@@ -35,9 +79,12 @@ grep '^configure\.ac:4:.*install.*compile' stderr
 test -f compile

 grep '^generic/a\.\$(OBJEXT):' Makefile.in
-grep '[^/]a\.\$(OBJEXT)' Makefile.in && exit 1
+grep '^generic/b\.\$(OBJEXT):' sub/Makefile.in
+grep '^another/z\.\$(OBJEXT):' Makefile.in
+$EGREP '(^|[^/])[abz]\.\$(OBJEXT)' Makefile.in sub/Makefile.in && exit 1

 # Opportunistically test for a different bug.
-grep '^generic/b\.\$(OBJEXT):.*dirstamp' Makefile.in
+grep '^another/z\.\$(OBJEXT):.*dirstamp' Makefile.in
+grep '^generic/b\.\$(OBJEXT):.*dirstamp' sub/Makefile.in

 :
diff --git a/t/subobj4.sh b/t/subobj4.sh
index 816f506..dbbed30 100755
--- a/t/subobj4.sh
+++ b/t/subobj4.sh
@@ -43,7 +43,7 @@ END
 : > d2/z.c

 $ACLOCAL
-$AUTOMAKE
+$AUTOMAKE -Wno-unsupported

 grep '\$(CC) .*\.\./d2/z\.c' d1/Makefile.in

diff --git a/t/subobj7.sh b/t/subobj7.sh
index 5dc9ea8..de73cc2 100755
--- a/t/subobj7.sh
+++ b/t/subobj7.sh
@@ -25,6 +25,7 @@ AC_OUTPUT
 END

 cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
 bin_PROGRAMS = wish
 wish_SOURCES = foo.c generic/a.c
 END
diff --git a/t/subpkg-yacc.sh b/t/subpkg-yacc.sh
index 639e415..9fc6761 100755
--- a/t/subpkg-yacc.sh
+++ b/t/subpkg-yacc.sh
@@ -49,7 +49,7 @@ mkdir lib/src

 cat >lib/configure.ac <<'EOF'
 AC_INIT([lib], [2.3])
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([subdir-objects])
 AC_PROG_RANLIB
 AC_PROG_YACC
 dnl This comes after YACC and RANLIB checks, deliberately.
diff --git a/t/subpkg.sh b/t/subpkg.sh
index 6f59ac5..f9cdc74 100755
--- a/t/subpkg.sh
+++ b/t/subpkg.sh
@@ -62,7 +62,7 @@ mkdir lib/src

 cat >lib/configure.ac <<'EOF'
 AC_INIT([lib], [2.3])
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([subdir-objects])
 AC_CONFIG_MACRO_DIR([../m4])
 AM_PROG_AR
 AC_PROG_RANLIB
diff --git a/t/suffix-custom-subobj-and-specflg.sh b/t/suffix-custom-subobj-and-specflg.sh
index 32356d7..b862d88 100755
--- a/t/suffix-custom-subobj-and-specflg.sh
+++ b/t/suffix-custom-subobj-and-specflg.sh
@@ -53,18 +53,9 @@ END
 $ACLOCAL
 $AUTOCONF
 $AUTOMAKE -a
-./configure
-$MAKE
-
-$MAKE distcheck
-$MAKE distclean
-
-# Should also work without subdir-objects.

-sed '/subdir-objects/d' < Makefile.am > t
-mv -f t Makefile.am
-$AUTOMAKE
 ./configure
+
 $MAKE
 $MAKE distcheck

diff --git a/t/vala-libs.sh b/t/vala-libs.sh
index 66fd243..f1ed99a 100755
--- a/t/vala-libs.sh
+++ b/t/vala-libs.sh
@@ -31,6 +31,7 @@ AC_OUTPUT
 END

 cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
 lib_LIBRARIES = libmu.a
 lib_LTLIBRARIES = src/libzardoz.la
 libmu_a_SOURCES = mu.vala mu2.c mu.vapi mu2.h
@@ -75,7 +76,7 @@ int main ()
 }
 END

-mkdir src
+mkdir -p src
 cat > src/zardoz-foo.vala << 'END'
 using GLib;
 public class Foo {
diff --git a/t/vala-non-recursive-setup.sh b/t/vala-non-recursive-setup.sh
index 88d9d33..88f67a8 100755
--- a/t/vala-non-recursive-setup.sh
+++ b/t/vala-non-recursive-setup.sh
@@ -39,6 +39,7 @@ public class Zardoz {
 END

 cat > 'Makefile.am' <<'END'
+AUTOMAKE_OPTIONS = subdir-objects
 bin_PROGRAMS = src/zardoz
 src_zardoz_CFLAGS = $(GOBJECT_CFLAGS)
 src_zardoz_LDADD = $(GOBJECT_LIBS)
diff --git a/t/yacc-grepping2.sh b/t/yacc-grepping2.sh
index 58a963c..3c5da22 100755
--- a/t/yacc-grepping2.sh
+++ b/t/yacc-grepping2.sh
@@ -34,7 +34,9 @@ mkdir sub
 : > sub/maude.y

 $ACLOCAL
-$AUTOMAKE -a
+# FIXME: stop disabling the warnings in the 'unsupported' category
+# FIXME: once the 'subdir-objects' option has been mandatory.
+$AUTOMAKE -a -Wno-unsupported

 grep '^maude\.c:.*maude\.y' Makefile.in

@@ -47,7 +49,6 @@ bin_PROGRAMS = maude
 maude_SOURCES = sub/maude.y
 END

-$ACLOCAL
 $AUTOMAKE -a

 # No rule needed, the default .y.c: inference rule is enough
@@ -64,8 +65,9 @@ maude_SOURCES = sub/maude.y
 maude_YFLAGS = -d
 END

-$ACLOCAL
-$AUTOMAKE -a
+# FIXME: stop disabling the warnings in the 'unsupported' category
+# FIXME: once the 'subdir-objects' option has been mandatory.
+$AUTOMAKE -a -Wno-unsupported

 # Rule should use maude_YFLAGS.
 grep 'AM_YFLAGS.*maude' Makefile.in && exit 1
diff --git a/t/yacc-line.sh b/t/yacc-line.sh
index 9067a2d..b034af3 100755
--- a/t/yacc-line.sh
+++ b/t/yacc-line.sh
@@ -76,7 +76,9 @@ c_outputs='zardoz.c bar-quux.c sub/foo-zardoz.c sub/dir/quux.c'

 $ACLOCAL
 $AUTOCONF
-$AUTOMAKE -a
+# FIXME: stop disabling the warnings in the 'unsupported' category
+# FIXME: once the 'subdir-objects' option has been mandatory.
+$AUTOMAKE -a -Wno-unsupported

 for vpath in : false; do

-- 
1.8.1.rc3.192.g2d0029e

Message #109 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o"
	is used with losing compilers
Date: Sun, 13 Jan 2013 21:40:49 +0100

On 01/13/2013 09:01 PM, Nick Bowler wrote:
> On 2013-01-12 11:05 +0100, Stefano Lattarini wrote:
>> On 01/11/2013 08:16 PM, Stefano Lattarini wrote:
>>> On 01/11/2013 07:19 PM, Eric Blake wrote:
>>>> On 01/10/2013 06:33 AM, Stefano Lattarini wrote:
>>>>> Reference:
>>>>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>
>>>>>
>>>>
>>>>>  @acindex AC_PROG_CC_C_O
>>>>> -This is like @code{AC_PROG_CC_C_O}, but it generates its results in
>>>>> -the manner required by Automake.  You must use this instead of
>>>>> -@code{AC_PROG_CC_C_O} when you need this functionality, that is, when
>>>>> -using per-target flags or subdir-objects with C sources.
>>>>> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
>>>>> +code needs not to use this macro.  It might be deprecated and
>>>>
>>>> s/needs not to/needs not/
>>>>
>>> Fixed, thanks.  I will soon merge the patch into maint.
>>>
>> Done.  Also merged maint into master, and pushed.
> 
> Hm, so much for waiting a week to push...
> 
No harm done.  We already have simplest and sanest semantics than before
(which is good).  If you patches make that even simpler and saner, we can
only rejoice :-).  That said, it would be really nice if you could you
rebase your changes on current maint (not master), and adjust the commit
messages to match.

> This all seems like needless complexity.
>
I didn't particularly care, since most of that complexity was expected to
either disappeared or be moved into Autoconf by the time of the Automake
1.14 release.  But if we can remove this complexity *today*, with no loss
in functionality and no complication in interfaces, well, I certainly
won't complain :-)

> It's unclear to me why
> my earlier suggestion (using AC_CONFIG_COMMANDS_PRE to expand
> AM_PROG_CC_C_O) was inadequate.
>
Mostly it got lost in the noise, and I didn't consider it carefully
enough.  Right now, I can't think of any problem with your approach.
So, unless somebody else objects or points out possible issues, I
believe that would be a better approach than mine.

> This would also require no changes to autoconf, and we would not
> need to deprecate AM_PROG_CC_C_O,
>
JFTR, we don't need to do so with my patch either.  AM_PROG_CC_C_O
is simply a no-op now.  Which I believe is good (see also my reply
to your second patch for more considerations about this).

> so no backwards compatibility hacks are required.
>
They already aren't required, luckily.

> These patches no longer apply to master,
>
They should go in maint, BTW, since the change is to appear in
Automake 1.13.2.

> but here they are anyway.
> 
> Nick Bowler (2):
>   Use AC_DEFUN_ONCE to define AM_PROG_CC_C_O.
>   Automatically call AM_PROG_CC_C_O as required.
> 
>  m4/init.m4   | 5 +++++
>  m4/minuso.m4 | 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 

Thanks,
  Stefano

Message #112 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.
Date: Sun, 13 Jan 2013 21:41:07 +0100

On 01/13/2013 09:01 PM, Nick Bowler wrote:
> If subdir-objects is made the default Automake behaviour, packages
> will need to add AM_PROG_CC_C_O to their configure.ac.  Instead of
> that, let's just make the functionality provided by AM_PROG_CC_C_O
> mandatory for C projects, and have Automake automatically call it
> as required.
> 
> This change should have no effect on packages which explicitly call
> AM_PROG_CC_C_O already.
> 
> * m4/init.m4: Have AM_INIT_AUTOMAKE arrange for AM_PROG_CC_C_O to be
> called if necessary.
> ---
>  m4/init.m4 | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/m4/init.m4 b/m4/init.m4
> index 7535706..6c48704 100644
> --- a/m4/init.m4
> +++ b/m4/init.m4
> @@ -109,6 +109,11 @@ AC_PROVIDE_IFELSE([AC_PROG_OBJCXX],
>  		  [m4_define([AC_PROG_OBJCXX],
>  			     m4_defn([AC_PROG_OBJCXX])[_AM_DEPENDENCIES([OBJCXX])])])dnl
>  ])
> +dnl Automatically invoke AM_PROG_CC_C_O as necessary.  Since AC_PROG_CC is
> +dnl usually called after AM_INIT_AUTOMAKE, we arrange for the test to be
> +dnl done later by AC_CONFIG_COMMANDS_PRE.
>
This would also have the advantage that we shouldn't worry about possible
$CC rewrites between the AC_PROG_CC and the AC_OUTPUT invocation.  Your
approach might actually be not only the simplest, but also the sanest one.

That said, I believe we'd still have to fix AM_PROG_CC_C_O not to rely on
the broken AC_PROG_CC_C_O semantics of checking *both* '$CC' and 'cc' for
"-c -o" support.  But that is quite orthogonal to your patch, and material
for a follow-up anyway.

Another useful follow-up would be to move the AM_PROG_CC_C_O in a private
macro (to be expanded in AC_CONFIG_COMMANDS_PRE like you did above), and
make AM_PROG_CC_C_O a no-op (without runtime deprecation).  That way, we
could rely on the improved semantic of having the potential '$CC' rewrite
placed near the end of configure, rather than near the beginning.  WDYT?

> +AC_CONFIG_COMMANDS_PRE([AC_PROVIDE_IFELSE([AC_PROG_CC],
> +  [AC_LANG([C]) AM_PROG_CC_C_O])])dnl
>  AC_REQUIRE([AM_SILENT_RULES])dnl
>  dnl The testsuite driver may need to know about EXEEXT, so add the
>  dnl 'am__EXEEXT' conditional if _AM_COMPILER_EXEEXT was seen.  This

Thanks,
  Stefano

Message #115 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> elliptictech.com>, Eric Blake <eblake <at> redhat.com>,
	13378 <at> debbugs.gnu.org,
	"automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#13378: Backward-compatibility in the autotools
Date: Mon, 14 Jan 2013 08:38:07 +1000

On 01/12/2013 04:45 AM, Stefano Lattarini wrote:
>> As a rule of thumb on when to remove a macro - I would personally like
>> >  being able to write a configure script that works on both RHEL 5 (or
>> >  CentOS 5) (autoconf 2.59, automake 1.9.6) as well as rawhide (eventually
>> >  automake 1.14 and beyond), for as long as RHEL 5 remains a viable
>> >  Enterprise-level distro.
>> >
> I'm quite unconvinced of the value in trying to support this.  Developers
> should just keep their tool reasonably up-to date IMHO; if they can't
> do so through their package manager, they should do so by installing
> from source.
Keeping autotools might be trivial in one-man-projects, but imposing 
that kind of requirement in larger teams is just causing head ache and 
friction, as most members wouldn't barely know what autotools are and 
even less interested in spending any time on upgrading tools that should 
just work under then hood.

Cheers,
Peter

Message #118 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is
	used with losing compilers
Date: Sun, 13 Jan 2013 15:01:35 -0500

On 2013-01-12 11:05 +0100, Stefano Lattarini wrote:
> On 01/11/2013 08:16 PM, Stefano Lattarini wrote:
> > On 01/11/2013 07:19 PM, Eric Blake wrote:
> >> On 01/10/2013 06:33 AM, Stefano Lattarini wrote:
> >>> Reference:
> >>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50>
> >>>
> >>
> >>>  @acindex AC_PROG_CC_C_O
> >>> -This is like @code{AC_PROG_CC_C_O}, but it generates its results in
> >>> -the manner required by Automake.  You must use this instead of
> >>> -@code{AC_PROG_CC_C_O} when you need this functionality, that is, when
> >>> -using per-target flags or subdir-objects with C sources.
> >>> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}.  New
> >>> +code needs not to use this macro.  It might be deprecated and
> >>
> >> s/needs not to/needs not/
> >>
> > Fixed, thanks.  I will soon merge the patch into maint.
> >
> Done.  Also merged maint into master, and pushed.

Hm, so much for waiting a week to push...

This all seems like needless complexity.  It's unclear to me why
my earlier suggestion (using AC_CONFIG_COMMANDS_PRE to expand
AM_PROG_CC_C_O) was inadequate.  This would also require no changes
to autoconf, and we would not need to deprecate AM_PROG_CC_C_O, so
no backwards compatibility hacks are required.

These patches no longer apply to master, but here they are anyway.

Nick Bowler (2):
  Use AC_DEFUN_ONCE to define AM_PROG_CC_C_O.
  Automatically call AM_PROG_CC_C_O as required.

 m4/init.m4   | 5 +++++
 m4/minuso.m4 | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
1.8.1

Message #121 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: [PATCH 1/2] Use AC_DEFUN_ONCE to define AM_PROG_CC_C_O.
Date: Sun, 13 Jan 2013 15:01:36 -0500

If AM_PROG_CC_C_O is expanded multiple times, and the compiler does not
support -c and -o together, each expansion of the macro will prepend
the compile script to CC.  This can result in the compile script
invoking the compile script, which at best pointless and silly.
Fortunately, there does not appear to be any serious problems as the
first compile invocation strips out -o options, causing subsequent
invocations of the script to merely exec their arguments.

Other than fixing the above, this should not normally cause any changes
to the resulting configure script, except in the (hopefully rare) case
where AM_PROG_CC_C_O is directly expanded (i.e., *not* using AC_REQUIRE)
in the body of a macro defined with AC_DEFUN.  In that case, the use of
AC_DEFUN_ONCE may cause the expansion of AM_PROG_CC_C_O to appear
earlier in the configure script.

* m4/minuso.m4: Change the definition of AM_PROG_CC_C_O to AC_DEFUN_ONCE,
avoiding problems caused by multiple expansions.
---
 m4/minuso.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/minuso.m4 b/m4/minuso.m4
index 984427c..06f74c9 100644
--- a/m4/minuso.m4
+++ b/m4/minuso.m4
@@ -8,7 +8,7 @@
 # AM_PROG_CC_C_O
 # --------------
 # Like AC_PROG_CC_C_O, but changed for automake.
-AC_DEFUN([AM_PROG_CC_C_O],
+AC_DEFUN_ONCE([AM_PROG_CC_C_O],
 [AC_REQUIRE([AC_PROG_CC_C_O])dnl
 AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
 AC_REQUIRE_AUX_FILE([compile])dnl
-- 
1.8.1

Message #124 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.
Date: Sun, 13 Jan 2013 15:01:37 -0500

If subdir-objects is made the default Automake behaviour, packages
will need to add AM_PROG_CC_C_O to their configure.ac.  Instead of
that, let's just make the functionality provided by AM_PROG_CC_C_O
mandatory for C projects, and have Automake automatically call it
as required.

This change should have no effect on packages which explicitly call
AM_PROG_CC_C_O already.

* m4/init.m4: Have AM_INIT_AUTOMAKE arrange for AM_PROG_CC_C_O to be
called if necessary.
---
 m4/init.m4 | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/m4/init.m4 b/m4/init.m4
index 7535706..6c48704 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -109,6 +109,11 @@ AC_PROVIDE_IFELSE([AC_PROG_OBJCXX],
 		  [m4_define([AC_PROG_OBJCXX],
 			     m4_defn([AC_PROG_OBJCXX])[_AM_DEPENDENCIES([OBJCXX])])])dnl
 ])
+dnl Automatically invoke AM_PROG_CC_C_O as necessary.  Since AC_PROG_CC is
+dnl usually called after AM_INIT_AUTOMAKE, we arrange for the test to be
+dnl done later by AC_CONFIG_COMMANDS_PRE.
+AC_CONFIG_COMMANDS_PRE([AC_PROVIDE_IFELSE([AC_PROG_CC],
+  [AC_LANG([C]) AM_PROG_CC_C_O])])dnl
 AC_REQUIRE([AM_SILENT_RULES])dnl
 dnl The testsuite driver may need to know about EXEEXT, so add the
 dnl 'am__EXEEXT' conditional if _AM_COMPILER_EXEEXT was seen.  This
-- 
1.8.1

Message #127 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.
Date: Sun, 13 Jan 2013 16:06:38 -0500

On 2013-01-13, Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
> On 01/13/2013 09:01 PM, Nick Bowler wrote:
>> +dnl Automatically invoke AM_PROG_CC_C_O as necessary.  Since AC_PROG_CC is
>> +dnl usually called after AM_INIT_AUTOMAKE, we arrange for the test to be
>> +dnl done later by AC_CONFIG_COMMANDS_PRE.
>
> This would also have the advantage that we shouldn't worry about possible
> $CC rewrites between the AC_PROG_CC and the AC_OUTPUT invocation.  Your
> approach might actually be not only the simplest, but also the sanest one.
>
> That said, I believe we'd still have to fix AM_PROG_CC_C_O not to rely on
> the broken AC_PROG_CC_C_O semantics of checking *both* '$CC' and 'cc' for
> "-c -o" support.  But that is quite orthogonal to your patch, and material
> for a follow-up anyway.

Well, that seem more like a something to change in Autoconf, not
requiring any change in Automake (except maybe we could also fix the
crazy cache variable naming scheme).  I admit I do not understand the
rationale for Autoconf testing "plain" cc in addition to the real
compiler.

> Another useful follow-up would be to move the AM_PROG_CC_C_O in a private
> macro (to be expanded in AC_CONFIG_COMMANDS_PRE like you did above), and
> make AM_PROG_CC_C_O a no-op (without runtime deprecation).  That way, we
> could rely on the improved semantic of having the potential '$CC' rewrite
> placed near the end of configure, rather than near the beginning.  WDYT?

With AC_CONFIG_COMMANDS_PRE, AM_PROG_CC_C_O would still be required if
package authors want to make use of the "compile" wrapper in configure
tests -- essentially, configure.ac can call AM_PROG_CC_C_O to force the
test to happen where it is needed, rather than just before AC_OUTPUT.

I think it'd be worthwhile to keep that working.

Cheers,
  Nick

Message #130 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: Re: bug#13378: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as
	required.
Date: Mon, 14 Jan 2013 11:23:00 +0100

On 01/13/2013 10:06 PM, Nick Bowler wrote:
> On 2013-01-13, Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
>
>> Another useful follow-up would be to move the AM_PROG_CC_C_O in a private
>> macro (to be expanded in AC_CONFIG_COMMANDS_PRE like you did above), and
>> make AM_PROG_CC_C_O a no-op (without runtime deprecation).  That way, we
>> could rely on the improved semantic of having the potential '$CC' rewrite
>> placed near the end of configure, rather than near the beginning.  WDYT?
> 
> With AC_CONFIG_COMMANDS_PRE, AM_PROG_CC_C_O would still be required if
> package authors want to make use of the "compile" wrapper in configure
> tests -- essentially, configure.ac can call AM_PROG_CC_C_O to force the
> test to happen where it is needed, rather than just before AC_OUTPUT.
> 
> I think it'd be worthwhile to keep that working.
>
Ah, but the $CC rewrite has always been an undocumented hack, and relying
on it is a bad idea.  Still, your reasoning makes it clear that changing
that semantics abruptly might cause subtle backward-incompatibilities in
corner-case but perfectly valid situations.  Hmmm...  I think it's better
to follow your approach for now, and then, if and when we decide to fix
our macros not to rewrite $CC, do so with proper NEWS and documentation
warnings beforehand, and a viable deprecation plan.

Thanks,
  Stefano

Message #133 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: "bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: Cleaning up AC_PROG_CC_C_O semantics (was: Re: [PATCH 2/2]
	Automatically call AM_PROG_CC_C_O as required.)
Date: Mon, 14 Jan 2013 11:24:17 +0100

[+cc bug-autoconf]

Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#127>

On 01/13/2013 10:06 PM, Nick Bowler wrote:
> On 2013-01-13, Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
>> On 01/13/2013 09:01 PM, Nick Bowler wrote:
>>> +dnl Automatically invoke AM_PROG_CC_C_O as necessary.  Since AC_PROG_CC is
>>> +dnl usually called after AM_INIT_AUTOMAKE, we arrange for the test to be
>>> +dnl done later by AC_CONFIG_COMMANDS_PRE.
>>
>> This would also have the advantage that we shouldn't worry about possible
>> $CC rewrites between the AC_PROG_CC and the AC_OUTPUT invocation.  Your
>> approach might actually be not only the simplest, but also the sanest one.
>>
>> That said, I believe we'd still have to fix AM_PROG_CC_C_O not to rely on
>> the broken AC_PROG_CC_C_O semantics of checking *both* '$CC' and 'cc' for
>> "-c -o" support.  But that is quite orthogonal to your patch, and material
>> for a follow-up anyway.
> 
> Well, that seem more like a something to change in Autoconf, not
> requiring any change in Automake (except maybe we could also fix the
> crazy cache variable naming scheme).  I admit I do not understand the
> rationale for Autoconf testing "plain" cc in addition to the real
> compiler.
>
Me neither.  However, if the autoconf developers agree that the current
AC_PROG_CC_C_O semantic is suboptimal and needlessly complex, and are willing
to change it in Autoconf 2.70, we could simply backport that change in
Automake 1.13.2, and then start relying on the new Autoconf behaviour in
Automake 1.14.

Autoconfers, WDYT?

Thanks,
  Stefano

Message #136 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> draconx.ca>, Eric Blake <eblake <at> redhat.com>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	13378 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: Cleaning up AC_PROG_CC_C_O semantics
Date: Mon, 14 Jan 2013 11:45:11 -0800

On 01/14/13 02:24, Stefano Lattarini wrote:
> Autoconfers, WDYT?

I think I'm lost.  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378
is a long thread.

Message #139 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Nick Bowler <nbowler <at> draconx.ca>, Eric Blake <eblake <at> redhat.com>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	13378 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: Cleaning up AC_PROG_CC_C_O semantics
Date: Mon, 14 Jan 2013 20:56:57 +0100

Hi Paul.

On 01/14/2013 08:45 PM, Paul Eggert wrote:
> On 01/14/13 02:24, Stefano Lattarini wrote:
>> Autoconfers, WDYT?
> 
> I think I'm lost.  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378
> is a long thread.
>
Yeah, sorry for not giving a more clear summary.

Here are the main grips I (and I guess Nick too) have with the current
AC_PROG_CC_C_O semantics:

  1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
     or 'clang') supports "-c -o" together.  Why?  If the user has a
     broken base vendor compiler, but has installed a better one (say
     GCC), why should he still be penalized?

  2. The fact the cache variable used by the test is based on the
     contents of the $CC expansion seems fragile and confusing.  AFICS,
     none of the other cache variables referring to check on the
     selected C compiler has this property -- so why should this one?

So, my question is: could any of this semantics be improved in the
obvious way in Autoconf 2.70?  If this is not doable in the pre-existing
macro for backward-compatibility considerations (and risking to introduce
incompatibilities a last minute change might indeed not be a good idea),
with a new one perhaps -- but public and documented this time, rather
than just an hack for Automake to exploit.

So, is the question clearer now?  If yes, what is your opinion?

Thanks,
  Stefano

Message #142 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> draconx.ca>, Eric Blake <eblake <at> redhat.com>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	13378 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: Cleaning up AC_PROG_CC_C_O semantics
Date: Mon, 14 Jan 2013 19:16:10 -0800

On 01/14/2013 11:56 AM, Stefano Lattarini wrote:
>   1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
>      or 'clang') supports "-c -o" together.  Why?  If the user has a
>      broken base vendor compiler, but has installed a better one (say
>      GCC), why should he still be penalized?

I don't know.  It's been that way for two decades or so, for no
reason that I can see.
 
>   2. The fact the cache variable used by the test is based on the
>      contents of the $CC expansion seems fragile and confusing.  AFICS,
>      none of the other cache variables referring to check on the
>      selected C compiler has this property -- so why should this one?

Again, no good reason that I can see.

> So, my question is: could any of this semantics be improved in the
> obvious way in Autoconf 2.70?  If this is not doable in the pre-existing
> macro for backward-compatibility considerations (and risking to introduce
> incompatibilities a last minute change might indeed not be a good idea),

We could have the change take effect only if some other macro is invoked,
indicating that the user wants the new behavior.  That should be safe.
The default behavior can be the old behavior for now, with the intent that
this will eventually change to the new behavior.

Message #145 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 13378 <at> debbugs.gnu.org
Cc: "automake-patches <at> gnu.org" <automake-patches <at> gnu.org>
Subject: Re: bug#13378: [PATCH] subdir-objects: complain if it isn't enabled
Date: Wed, 16 Jan 2013 13:31:57 +0100

On 01/13/2013 08:51 PM, Stefano Lattarini wrote:
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378>
> 
> On 01/07/2013 09:08 PM, Stefano Lattarini wrote:
>> Severity: wishlist
>>
>> Inspired from Automake-NG commit 'v1.12.1-313-g14fe163' of 2012-06-07,
>> "[ng] subdir-objects: enable unconditionally".
>>
>> The fact that Automake-generated Makefiles place compiled object files in
>> he current directory by default, also when the corresponding source file
>> is in a subdirectory, is basically an historical accident, due to the fact
>> that the 'subdir-objects' option had only been introduced in April 1999,
>> starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never
>> made the default (likely to avoid backwards-compatibility issues).
>>
>> Since I believe the behaviour enabled by the 'subdir-objects' is the most
>> useful one, and in fact the *only* natural one, I'd like to make it the
>> the only one available, simplifying the Automake implementation and APIs
>> a little in the process.
>>
>> Alas, since this also means changing the default behaviour of Automake
>> ('subdir-objects' is not enabled by default, sadly), this means the
>> transition path will be less smooth than I'd like.  Here it is a sketch
>> for it:
>>
>>   Automake 1.13.2
>>   ---------------
>>
>>   Give a warning in the category 'unsupported' if the 'subdir-objects'
>>   option is not specified.  This should give the users enough forewarning
>>   about the planned change, and give them time to update their packages
>>   to the new semantic.
>>
> Here is a patch doing that.  I will push it in a couple of days if there
> are no objections.
> 
> Regards,
>   Stefano
> 
> ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----
> 
> From 4864af66bfd189a501061d775bb9743a1285d88e Mon Sep 17 00:00:00 2001
> Message-Id: <4864af66bfd189a501061d775bb9743a1285d88e.1358106576.git.stefano.lattarini <at> gmail.com>
> From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
> Date: Sun, 13 Jan 2013 17:50:30 +0100
> Subject: [PATCH] subdir-objects: complain if it isn't enabled
> 
> Since the next major automake version will make the behaviour so far
> only activated with the 'subdir-object' option mandatory, it's better
> if we start warning users not using that option.
> 
> As suggested by Peter Johansson, we strive to avoid the warning when
> it would be irrelevant, i.e., if all source files sit in "current"
> directory.
> 
> See automake bug#13378.
> 
> * automake.in (handle_single_transform): Print the warning when
> necessary.
> * t/subobj.sh: Enhance.
> * t/ax/depcomp.sh: Adjust.
> * t/cscope.tap: Likewise.
> * t/depcomp8a.sh: Likewise.
> * t/depcomp8b.sh: Likewise.
> * t/ext2.sh: Likewise.
> * t/extra-portability.sh: Likewise.
> * t/fort2.sh: Likewise.
> * t/fort4.sh: Likewise.
> * t/fort5.sh: Likewise.
> * t/lex-line.sh: Likewise.
> * t/libtool3.sh: Likewise.
> * t/ltinstloc.sh: Likewise.
> * t/ltlibsrc.sh: Likewise.
> * t/ltorder.sh: Likewise.
> * t/parallel-tests-suffix-prog.sh: Likewise.
> * t/sourcefile-in-subdir.sh: Likewise.
> * t/specflg9.sh: Likewise.
> * t/subobj4.sh: Likewise.
> * t/subobj7.sh: Likewise.
> * t/subpkg-yacc.sh: Likewise.
> * t/subpkg.sh: Likewise.
> * t/suffix-custom-subobj-and-specflg.sh: Likewise.
> * t/vala-libs.sh: Likewise.
> * t/vala-non-recursive-setup.sh: Likewise.
> * t/yacc-grepping2.sh: Likewise.
> * t/yacc-line.sh: Likewise.
>
Pushed now.

Regards,
  Stefano

Message #148 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Nick Bowler <nbowler <at> draconx.ca>, Eric Blake <eblake <at> redhat.com>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	13378 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics
Date: Wed, 16 Jan 2013 13:46:22 +0100

On 01/15/2013 04:16 AM, Paul Eggert wrote:
> On 01/14/2013 11:56 AM, Stefano Lattarini wrote:
>>   1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
>>      or 'clang') supports "-c -o" together.  Why?  If the user has a
>>      broken base vendor compiler, but has installed a better one (say
>>      GCC), why should he still be penalized?
> 
> I don't know.  It's been that way for two decades or so, for no
> reason that I can see.
>  
>>   2. The fact the cache variable used by the test is based on the
>>      contents of the $CC expansion seems fragile and confusing.  AFICS,
>>      none of the other cache variables referring to check on the
>>      selected C compiler has this property -- so why should this one?
> 
> Again, no good reason that I can see.
> 
>> So, my question is: could any of this semantics be improved in the
>> obvious way in Autoconf 2.70?  If this is not doable in the pre-existing
>> macro for backward-compatibility considerations (and risking to introduce
>> incompatibilities a last minute change might indeed not be a good idea),
> 
> We could have the change take effect only if some other macro is invoked,
> indicating that the user wants the new behavior.  That should be safe.
> The default behavior can be the old behavior for now, with the intent that
> this will eventually change to the new behavior.
> 
Makes sense.  Should I try to implement something along these lines (might
take a few days), or are you planning to do that yourself (in which case
I'll avoid the duplicated efforts)?

Thanks,
  Stefano

Message #151 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> draconx.ca>, Eric Blake <eblake <at> redhat.com>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	13378 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics
Date: Wed, 16 Jan 2013 09:48:31 -0800

On 01/16/13 04:46, Stefano Lattarini wrote:
> Makes sense.  Should I try to implement something along these lines (might
> take a few days), or are you planning to do that yourself (in which case
> I'll avoid the duplicated efforts)?

I wasn't planning on doing that, so please go ahead.

Message #154 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Nick Bowler <nbowler <at> draconx.ca>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>,
	13378 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics
Date: Wed, 16 Jan 2013 11:24:54 -0700

[Message part 1 (text/plain, inline)]

On 01/16/2013 10:48 AM, Paul Eggert wrote:
> On 01/16/13 04:46, Stefano Lattarini wrote:
>> Makes sense.  Should I try to implement something along these lines (might
>> take a few days), or are you planning to do that yourself (in which case
>> I'll avoid the duplicated efforts)?
> 
> I wasn't planning on doing that, so please go ahead.

Didn't you already add _AM_PROG_CC_C_O_HELPME; is that a sufficient
witness macro for whether to use the proposed cleanups?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #157 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> draconx.ca>, Paul Eggert <eggert <at> cs.ucla.edu>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	13378 <at> debbugs.gnu.org, automake-patches <at> gnu.org
Subject: Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics
Date: Wed, 16 Jan 2013 20:46:27 +0100

On 01/16/2013 07:24 PM, Eric Blake wrote:
> On 01/16/2013 10:48 AM, Paul Eggert wrote:
>> On 01/16/13 04:46, Stefano Lattarini wrote:
>>> Makes sense.  Should I try to implement something along these lines (might
>>> take a few days), or are you planning to do that yourself (in which case
>>> I'll avoid the duplicated efforts)?
>>
>> I wasn't planning on doing that, so please go ahead.
> 
> Didn't you already add _AM_PROG_CC_C_O_HELPME; is that a sufficient
> witness macro for whether to use the proposed cleanups?
> 
Indeed that is enough for Automake's current needs.  But that hook is
currently in AC_PROG_CC, while Nick's proposal involved having something
like that in AC_PROG_CC_C_O, for which AM_PROG_CC_C_O would continue to
be a thin wrapper (but automatically invoked by AC_CONFIG_COMMANDS_PRE
whenever needed).

Regards,
  Stefano

Message #160 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Nick Bowler <nbowler <at> draconx.ca>, Eric Blake <eblake <at> redhat.com>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics
Date: Sat, 19 Jan 2013 14:10:28 +0100

[-cc automake-patches]

On 01/16/2013 06:48 PM, Paul Eggert wrote:
> On 01/16/13 04:46, Stefano Lattarini wrote:
>> Makes sense.  Should I try to implement something along these lines (might
>> take a few days), or are you planning to do that yourself (in which case
>> I'll avoid the duplicated efforts)?
> 
> I wasn't planning on doing that, so please go ahead.
>
Here is my attempt.  OK to go in Autoconf 2.70?

Thanks,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From 6d20ebf0abd4e08f0c7793d36d57ac9037026e05 Mon Sep 17 00:00:00 2001
Message-Id: <6d20ebf0abd4e08f0c7793d36d57ac9037026e05.1358600662.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Sat, 19 Jan 2013 13:32:44 +0100
Subject: [PATCH] AC_PROG_CC_C_O: allow for improved semantics

The current semantics of AC_PROG_CC_C_O have two serious shortcomings,
that make the use of that macro in Automake problematic:

 1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
    or 'clang') supports "-c -o" together.  Why?  If the user has a
    broken base vendor compiler, but has installed a better one (say
    GCC), why should he still be penalized?  This behaviour is very
    likely only due to historical reasons, and has no good rationale
    today.

 2. The name of the cache variable used by this macro is based on the
    contents of the $CC expansion, rather than following the usual
    'ac_cv_cc_*' pattern.  This is fragile and confusing.  In addition,
    none of the other cache variables referring to check on the
    selected C compiler has this property -- so why should this one?
    Again, no good reasons come to mind (apart for "historical" ones).

For backward-compatibility reasons, we can't change these behaviours
abruptly; so, we implement a new saner behaviour, but don't make it
the default yet, instead allowing the user to explicitly request it
by defining the witness macro 'AC_PROG_CC_C_O_USE_MODERN_SEMANTICS'.
Future versions of Automake will thus define that macro to enable the
desired behaviour.

As a consequence of this change, we can drop the Automake-specific
private (and hacky) hook that has been added to AC_PROG_CC in past
commit 'v2.69-63-gce48964': Automake no longer plan to use it.

This change has been motivated by the on-going work on Automake and
its 'subdir-object' mode (see automake bug#13378).  See also:
<http://lists.gnu.org/archive/html/bug-autoconf/2013-01/msg00034.html>

* NEWS: Update.
* doc/autoconf.texi: Likewise.
* lib/autoconf/c.m4 (AC_PROG_CC_C_O): If the witness macro
'AC_PROG_CC_C_O_USE_MODERN_SEMANTICS' is defined:
  - check support for "-c -o" only for the currently selected C
    compiler '$CC', and not also the "system" one 'cc'
  - unconditionally use 'ac_cv_prog_cc_c_o' as the cache variable
    for this check, instead of a cache variable name based on the
    expansion of $CC.
(AC_PROG_CC): Drop Automake-specific hook enabled when the
witness macro '_AM_PROG_CC_C_O_HELPME' was defined.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 NEWS              |  5 +++++
 doc/autoconf.texi | 31 ++++++++++++++++++++++++-------
 lib/autoconf/c.m4 | 46 ++++++++++++++--------------------------------
 3 files changed, 43 insertions(+), 39 deletions(-)

diff --git a/NEWS b/NEWS
index a9b2226..9e18436 100644
--- a/NEWS
+++ b/NEWS
@@ -28,6 +28,11 @@ GNU Autoconf NEWS - User visible changes.
 - AC_PROG_CC_STDC, AC_PROG_CC_C89, AC_PROG_CC_C99 have been marked as obsolete.
   Applications should use AC_PROG_CC.

+- AC_PROG_CC_C_O implements saner semantics if the new witness macro
+  AC_PROG_CC_C_O_USE_MODERN_SEMANTICS is defined (see the documentation
+  for details).  Future versions of autoconf might make such new
+  semantics the default at some point.
+
 - AC_FUNC_VFORK now checks for the signal-handling bug in Solaris 2.4 'vfork'.
   Formerly, it ignored this bug, so that Emacs could use some tricky
   code on that platform.  Solaris 2.4 has not been supported since
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index bb83443..c1e89d7 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7304,17 +7304,34 @@ needless reexpansion (@pxref{One-Shot Macros}).
 @acindex{PROG_CC_C_O}
 @cvindex NO_MINUS_C_MINUS_O
 @caindex prog_cc_ <at> var{compiler}_c_o
+@caindex prog_cc_c_o
 If the C compiler does not accept the @option{-c} and @option{-o} options
-simultaneously, define @code{NO_MINUS_C_MINUS_O}.  This macro actually
-tests both the compiler found by @code{AC_PROG_CC}, and, if different,
-the first @code{cc} in the path.  The test fails if one fails.  This
-macro was created for GNU Make to choose the default C compilation
-rule.
+simultaneously, define @code{NO_MINUS_C_MINUS_O}.

-For the compiler @var{compiler}, this macro caches its result in the
+This macro has two modes of behavior, the historical one and a new
+sanest one, both described just below.  The historical mode is the
+default for the moment, but this might change in future autoconf
+versions.
+
+@itemize
+
+@item
+In the ``historical'' mode (originally created for GNU Make to choose
+the default C compilation rule), both the compiler @code{$CC} found by
+@code{AC_PROG_CC}, and, if different, the first @code{cc} in @env{PATH}
+are tested.  The test fails if one fails.  If @code{$CC} expands to
+@var{compiler}, the result of the check is cached in the
 @code{ac_cv_prog_cc_ <at> var{compiler}_c_o} variable.
-@end defmac

+@item
+In the ``new'' mode (enabled whenever the witness macro
+@code{AC_PROG_CC_C_O_USE_MODERN_SEMANTICS} is defined), only the compiler
+@code{$CC} found by @code{AC_PROG_CC} is tested, and the result of this
+check is cached in the @code{ac_cv_prog_cc_c_o} variable.
+
+@end itemize
+
+@end defmac

 @defmac AC_PROG_CPP
 @acindex{PROG_CPP}
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index affd765..90cd696 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -490,31 +490,6 @@ _AC_PROG_CC_C11([ac_prog_cc_stdc=c11
 		       ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89],
 		      [ac_prog_cc_stdc=no
 		       ac_cv_prog_cc_stdc=no])])])
-dnl This is a hook for Automake and its 'subdir-objects' mode, which
-dnl needs to know whether $CC supports "-c -o" together or not.  See
-dnl automake bug#13378, in particular <http://debbugs.gnu.org/13378#73>.
-dnl FIXME: there is some code duplication with AC_PROG_CC_C_O here.
-m4_ifdef([_AM_PROG_CC_C_O_HELPME],
-[set dummy $CC; ac_cc=`AS_ECHO(["$[2]"]) | \
-                       sed 's/[[^a-zA-Z0-9_]]/_/g;s/^[[0-9]]/_/'`
-AC_MSG_CHECKING([whether $CC understands -c and -o together])
-AC_CACHE_VAL([ac_cv_prog_cc_${ac_cc}_c_o],
-[AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
-# Make sure it works both with $CC and with simple cc.
-# We do the test twice because some compilers refuse to overwrite an
-# existing .o file with -o, though they will create one.
-ac_try='$CC -c conftest.$ac_ext -o conftest2.$ac_objext >&AS_MESSAGE_LOG_FD'
-rm -f conftest2.*
-if _AC_DO_VAR(ac_try) && test -f conftest2.$ac_objext
-then
-  AC_MSG_RESULT([yes])
-  eval ac_cv_prog_cc_${ac_cc}_c_o=yes
-else
-  AC_MSG_RESULT([no])
-  eval ac_cv_prog_cc_${ac_cc}_c_o=no
-fi
-rm -f core conftest*
-])])dnl
 AC_LANG_POP(C)dnl
 ])# AC_PROG_CC

@@ -589,14 +564,20 @@ fi
 # --------------
 AC_DEFUN([AC_PROG_CC_C_O],
 [AC_REQUIRE([AC_PROG_CC])dnl
-if test "x$CC" != xcc; then
+m4_ifdef([AC_PROG_CC_C_O_USE_MODERN_SEMANTICS],
+[AC_MSG_CHECKING([whether $CC understands -c and -o together])
+dnl Our cache variable will be simply named 'ac_cv_prog_cc_c_o',
+dnl but we keep this indirection to reduce code duplication, below.
+_ac_prog_cc_c_o_cache_var=ac_cv_prog_cc_c_o],
+[if test "x$CC" != xcc; then
   AC_MSG_CHECKING([whether $CC and cc understand -c and -o together])
 else
   AC_MSG_CHECKING([whether cc understands -c and -o together])
 fi
 set dummy $CC; ac_cc=`AS_ECHO(["$[2]"]) |
 		      sed 's/[[^a-zA-Z0-9_]]/_/g;s/^[[0-9]]/_/'`
-AC_CACHE_VAL(ac_cv_prog_cc_${ac_cc}_c_o,
+_ac_prog_cc_c_o_cache_var=ac_cv_prog_cc_${ac_cc}_c_o])
+AC_CACHE_VAL([$_ac_prog_cc_c_o_cache_var],
 [AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
 # Make sure it works both with $CC and with simple cc.
 # We do the test twice because some compilers refuse to overwrite an
@@ -606,7 +587,8 @@ rm -f conftest2.*
 if _AC_DO_VAR(ac_try) &&
    test -f conftest2.$ac_objext && _AC_DO_VAR(ac_try);
 then
-  eval ac_cv_prog_cc_${ac_cc}_c_o=yes
+  eval $_ac_prog_cc_c_o_cache_var=yes
+  m4_ifndef([AC_PROG_CC_C_O_USE_MODERN_SEMANTICS], [
   if test "x$CC" != xcc; then
     # Test first that cc exists at all.
     if _AC_DO_TOKENS(cc -c conftest.$ac_ext >&AS_MESSAGE_LOG_FD); then
@@ -619,16 +601,16 @@ then
 	:
       else
 	# cc exists but doesn't like -o.
-	eval ac_cv_prog_cc_${ac_cc}_c_o=no
+	eval $_ac_prog_cc_c_o_cache_var=no
       fi
     fi
-  fi
+  fi])
 else
-  eval ac_cv_prog_cc_${ac_cc}_c_o=no
+  eval $_ac_prog_cc_c_o_cache_var=no
 fi
 rm -f core conftest*
 ])dnl
-if eval test \$ac_cv_prog_cc_${ac_cc}_c_o = yes; then
+if eval test \${$_ac_prog_cc_c_o_cache_var} = yes; then
   AC_MSG_RESULT([yes])
 else
   AC_MSG_RESULT([no])
-- 
1.8.1.rc3.192.g2d0029e

Message #163 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Nick Bowler <nbowler <at> draconx.ca>, Paul Eggert <eggert <at> cs.ucla.edu>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics
Date: Sat, 19 Jan 2013 07:25:35 -0700

[Message part 1 (text/plain, inline)]

On 01/19/2013 06:10 AM, Stefano Lattarini wrote:
> [-cc automake-patches]
> 
> On 01/16/2013 06:48 PM, Paul Eggert wrote:
>> On 01/16/13 04:46, Stefano Lattarini wrote:
>>> Makes sense.  Should I try to implement something along these lines (might
>>> take a few days), or are you planning to do that yourself (in which case
>>> I'll avoid the duplicated efforts)?
>>
>> I wasn't planning on doing that, so please go ahead.
>>
> Here is my attempt.  OK to go in Autoconf 2.70?

Close, but I have some ideas for improvements.

> 
> +- AC_PROG_CC_C_O implements saner semantics if the new witness macro
> +  AC_PROG_CC_C_O_USE_MODERN_SEMANTICS is defined (see the documentation
> +  for details).  Future versions of autoconf might make such new
> +  semantics the default at some point.

Thnking about a forward-compatibility issue - what happens if, when we
switch semantics, someone still needs to get back to the old semantics?
 Do we add yet another witness macro at that time?  And how does such a
package work with both old and new autoconf at once?

Rather, a better plan is to make AC_PROG_CC_C_O be configurable via a
single witness, by taking an optional argument that determines _which_
semantics to use and having the witness be a non-empty string to alter
defaults.  All existing versions of autoconf ignore macro arguments to
AC_PROG_CC_C_O, so we can add an optional argument, and document it as
follows:

===============
AC_PROG_CC_C_O([mode])
----------------------
If MODE is given with the value 'sane', use the new semantics (for 2.70
and beyond). If MODE is given with the value 'old' (or for 2.69 and
earlier), use the backwards-compatible semantics.  If MODE is omitted,
which of the two semantics will default to the value of the macro
AC_PROG_CC_C_O_MODE (for 2.70 and beyond).

AC_PROG_CC_C_O_MODE
-------------------
This macro is predefined in autoconf 2.70 to have the value 'old'; but
packages may redefine it to contain 'sane' to impact how AC_PROG_CC_C_O
will behave if called without arguments.  A future version of autoconf
may switch this macro to have the value 'sane'.
==============

Usage wise, a configure.ac that uses AC_PROG_CC_C_O([old]) will always
have old semantics, regardless of which autoconf version it is built
with.  A configure.ac that uses AC_PROG_CC_C_O without arguments (most
existing scripts) will default to old semantics under older automake;
but Automake 1.14 can do 'm4_define([AC_PROG_CC_C_O_MODE], [sane])' at
initialization time, to take advantage of sane semantics.

Implementation-wise, it would look something like this in autoconf 2.70
(rough draft):

m4_define([AC_PROG_CC_C_O_MODE], [old])
m4_defun([AC_PROG_CC_C_O],
[m4_if(m4_default([$1], [m4_default(AC_PROG_CC_C_O_MODE, [old])]),
  [old], [old semantics],
  [new semantics])])

or, if we wanted to reject invalid input (rather than silently treating
all strings != 'old' as 'sane'):

m4_define([AC_PROG_CC_C_O_MODE], [old])
m4_defun([AC_PROG_CC_C_O],
[m4_case(m4_default([$1], [m4_default(AC_PROG_CC_C_O_MODE, [old])]),
  [old], [old semantics],
  [sane], [new semantics],
  [m4_fatal([unrecognized mode: $1])])])

Either way, you need only switch one line in a future autoconf to
default to new semantics.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #166 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> draconx.ca>, Paul Eggert <eggert <at> cs.ucla.edu>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>, 13378 <at> debbugs.gnu.org
Subject: Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics
Date: Mon, 21 Jan 2013 14:57:15 +0100

Hi Eric.

On 01/19/2013 03:25 PM, Eric Blake wrote:
> On 01/19/2013 06:10 AM, Stefano Lattarini wrote:
>> [-cc automake-patches]
>>
>> On 01/16/2013 06:48 PM, Paul Eggert wrote:
>>> On 01/16/13 04:46, Stefano Lattarini wrote:
>>>> Makes sense.  Should I try to implement something along these lines (might
>>>> take a few days), or are you planning to do that yourself (in which case
>>>> I'll avoid the duplicated efforts)?
>>>
>>> I wasn't planning on doing that, so please go ahead.
>>>
>> Here is my attempt.  OK to go in Autoconf 2.70?
> 
> Close, but I have some ideas for improvements.
> 
> [SNIP]
>
All your suggestions sound good, but I won't have time to fix my patch
to accommodate them in the short term.  If you want to take over from
here, feel free to; otherwise, let's put this topic on hold for the
moment.

Thanks,
  Stefano

Message #169 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: More work on subdir-objects, AC_PROG_CC and AM_PROG_CC_C_O
Date: Sat, 11 May 2013 11:57:30 +0200

[Message part 1 (text/plain, inline)]

Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#130>

Hello everybody, sorry for the delay.  This follow-up is looong
overdue.

On 01/14/2013 11:23 AM, Stefano Lattarini wrote:
> On 01/13/2013 10:06 PM, Nick Bowler wrote:
>> On 2013-01-13, Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
>>
>>> Another useful follow-up would be to move the AM_PROG_CC_C_O in a private
>>> macro (to be expanded in AC_CONFIG_COMMANDS_PRE like you did above), and
>>> make AM_PROG_CC_C_O a no-op (without runtime deprecation).  That way, we
>>> could rely on the improved semantic of having the potential '$CC' rewrite
>>> placed near the end of configure, rather than near the beginning.  WDYT?
>>
>> With AC_CONFIG_COMMANDS_PRE, AM_PROG_CC_C_O would still be required if
>> package authors want to make use of the "compile" wrapper in configure
>> tests -- essentially, configure.ac can call AM_PROG_CC_C_O to force the
>> test to happen where it is needed, rather than just before AC_OUTPUT.
>>
>> I think it'd be worthwhile to keep that working.
>>
> Ah, but the $CC rewrite has always been an undocumented hack, and relying
> on it is a bad idea.  Still, your reasoning makes it clear that changing
> that semantics abruptly might cause subtle backward-incompatibilities in
> corner-case but perfectly valid situations.  Hmmm...  I think it's better
> to follow your approach for now, and then, if and when we decide to fix
> our macros not to rewrite $CC, do so with proper NEWS and documentation
> warnings beforehand, and a viable deprecation plan.
> 
The attached patches implement Nick's suggestion on the current code
base (original patches from Nick has unfortunately gotten too much
out-of-sync with the current codebase situation).  But note that the
second (one-liner) is actually identical to the first patch originally
posted by Nick <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#121>,
so it's still in his name.

I plan to push these patches to maint in a couple of days if there is
no objection.

Regards,
  Stefano

[0001-compile-avoid-AC_PROG_CC-messy-rewrite.patch (text/x-patch, attachment)]

[0002-Use-AC_DEFUN_ONCE-to-define-AM_PROG_CC_C_O.patch (text/x-patch, attachment)]

Message #172 received at 13378 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: Eric Blake <eblake <at> redhat.com>, 13378 <at> debbugs.gnu.org,
	automake-patches <at> gnu.org
Subject: Re: bug#13378: More work on subdir-objects,
	AC_PROG_CC and AM_PROG_CC_C_O
Date: Mon, 13 May 2013 22:11:03 +0200

On 05/11/2013 11:57 AM, Stefano Lattarini wrote:
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#130>
> 
> Hello everybody, sorry for the delay.  This follow-up is looong
> overdue.
> 
> On 01/14/2013 11:23 AM, Stefano Lattarini wrote:
>> On 01/13/2013 10:06 PM, Nick Bowler wrote:
>>> On 2013-01-13, Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
>>>
>>>> Another useful follow-up would be to move the AM_PROG_CC_C_O in a private
>>>> macro (to be expanded in AC_CONFIG_COMMANDS_PRE like you did above), and
>>>> make AM_PROG_CC_C_O a no-op (without runtime deprecation).  That way, we
>>>> could rely on the improved semantic of having the potential '$CC' rewrite
>>>> placed near the end of configure, rather than near the beginning.  WDYT?
>>>
>>> With AC_CONFIG_COMMANDS_PRE, AM_PROG_CC_C_O would still be required if
>>> package authors want to make use of the "compile" wrapper in configure
>>> tests -- essentially, configure.ac can call AM_PROG_CC_C_O to force the
>>> test to happen where it is needed, rather than just before AC_OUTPUT.
>>>
>>> I think it'd be worthwhile to keep that working.
>>>
>> Ah, but the $CC rewrite has always been an undocumented hack, and relying
>> on it is a bad idea.  Still, your reasoning makes it clear that changing
>> that semantics abruptly might cause subtle backward-incompatibilities in
>> corner-case but perfectly valid situations.  Hmmm...  I think it's better
>> to follow your approach for now, and then, if and when we decide to fix
>> our macros not to rewrite $CC, do so with proper NEWS and documentation
>> warnings beforehand, and a viable deprecation plan.
>>
> The attached patches implement Nick's suggestion on the current code
> base (original patches from Nick has unfortunately gotten too much
> out-of-sync with the current codebase situation).  But note that the
> second (one-liner) is actually identical to the first patch originally
> posted by Nick <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#121>,
> so it's still in his name.
> 
> I plan to push these patches to maint in a couple of days if there is
> no objection.
> 
Patches pushed.

Regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.