On 08/06/2012 11:20 AM, Michał Górny wrote: > On Mon, 06 Aug 2012 09:38:08 +0200 > Stefano Lattarini <stefano.lattar...@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
