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

[Michał Górny]

On Mon, 06 Aug 2012 09:38:08 +0200
Stefano Lattarini <address@hidden> 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

> > 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.

> > - 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?

Just removing the second '.SUFFIXES: ...' line helps indeed. 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.

-- 
Best regards,
Michał Górny

signature.asc
Description: PGP signature