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

[Stefano Lattarini]

On 08/06/2012 10:41 AM, Jack Kelly wrote:
> On Mon, Aug 6, 2012 at 5:38 PM, Stefano Lattarini
> <address@hidden> wrote:
>> On 08/05/2012 11:45 AM, Michał Górny wrote:
>>> 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 ...
> 
> I have a feeling it's mimicking the way modern C++ prefers `#include
> <iostream>' over `#include <iostream.h>'
> 
> I propose a third fix: move the header file into a separate directory
> such as `include/' and add `-I$(top_srcdir)/include' to AM_CPPFLAGS.
>
This seems unwarranted complexity just for the sake of an eye-candy
like "#include <foo>" over "#include <foo.h>".  But of course, that
is for the OP to decide.

> Is it worth providing a way to disable implicit rules as an option to
> AM_INIT_AUTOMAKE or via the AUTOMAKE_OPTIONS variable?
>
Trying to do that portably would be a nightmare I think (assuming it would
be possible at all).  OTOH, Automake-NG (the Automake fork whose generated
Makefiles only target GNU make) does that unconditionally (for performance
rather than correctness reasons):

 <http://lists.gnu.org/archive/html/automake-ng/2012-06/msg00294.html>

> It's not enough to pass --no-builtin-rules to AM_MAKEFLAGS as I don't
> know if that's portable.
>
In fact, it's not.

> Further, the MAKEFLAGS only get propagated to submakes: the
> top-level make has already loaded the implicit rules before it sees
> MAKEFLAGS.
> 
Luckily, with GNU make, you can append to MAKEFLAGS in the Makefile:

  MAKEFLAGS += -r

and have that take effect in the current make run as well.

Regards,
  Stefano