GNU bug report logs - #12142
automake tries to compile a program when 'foo' and 'foo.cxx' exist (though the former is header)

Previous Next

Full log

View this message in rfc822 format

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Michał Górny <mgorny <at> gentoo.org>
Cc: 12142 <at> debbugs.gnu.org
Subject: bug#12142: automake tries to compile a program when 'foo' and 'foo.cxx' exist (though the former is header)
Date: Tue, 07 Aug 2012 18:12:42 +0200

On 08/06/2012 11:20 AM, Michał Górny wrote:
> On Mon, 06 Aug 2012 09:38:08 +0200
> Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
> 
>> On 08/05/2012 11:45 AM, Michał Górny wrote:
>>> autoconf: 2.69
>>> automake: 1.12.2
>>> libtool: 2.4.2
>>>
>> Also, which version of make are you using?
> 
> GNU Make 3.82
>
OK, as I assumed.

>>> My library was structured like the following:
>>>
>>> - src/foo (the header file),
>>>
>> Why not simply using a more usual name like 'foo.h' for 'foo.hxx'?
>> That would be unlikely to trigger unexpected problems in the first
>> place ...
> 
> Because it is a legit name.
>
I'm not contending that, but if it's causing problems due to bugs or
limitations of other important tools (GNU make, in this case), it would
be a good idea not to do so anyway IMHO.  Of course, you can agree to
differ on this.

>>> - src/foo.cxx (the code).
>>>
>>> These files assemble a library, let's call it libfoo.la.
>>>
>>> The problem is that every time I modify src/foo.cxx and call 'make',
>>> automake
>>>
>> No, automake is doing nothing at this point.  It's make that does the
>> building and compiling, using both the instructions given in the
>> Automake-generated Makefile and its own built-in rules.  And it's one
>> the latter that is wreaking havoc here.
>>
>>  first (correctly) compiles the library, and then mistakenly
>>> tries to compile and link it into a program src/foo, either
>>> effectively overwriting or removing my header file, or failing
>>> early due to missing dependency file.
>>>
>> I guess this doesn't happen if you run make with the
>> '--no-builtin-rules' option.  And in fact ...
> 
> You are right indeed. However, AFAICS it's not exactly that simple.
> Automake-generated Makefile first clears the default suffix list, then
> explicitly adds new suffixes. Is there a reason for that?
>
Portability to some vendor make I believe.

> Just removing the second '.SUFFIXES: ...' line helps indeed.
>
But that will cause the '.cxx.o' suffix rule to stop working with
some make implementations.  That's not something I prepared to
risk lightly.

> Yet it's
> probably not as portable as I'd like it to be. Still, it's worth
> considering if the explicit suffix list is beneficial at all.
>
I wouldn't if we could use pattern rules rather than suffix rules
(Automake-NG does exactly that).  But of course, they are not
portable :-(

Regards,
  Stefano

Previous Next

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