On Sunday 16 October 2011, Ralf Wildenhues wrote: > Hello, > Hi Ralf.
> * Stefano Lattarini wrote on Sun, Oct 16, 2011 at 08:27:12PM CEST: > > On Sunday 15 November 2009, Peter Johansson wrote: > > > make: *** No rule to make target `aminclude.am', needed by > > > `Makefile.in'. Stop. > > > > > > This is very similar to the "deleted header file problem" for *.m4 files > > > that was fixed in version 1.11 by adding a stub rule. I suppose this > > > problem could be solved in the same fashion. > > > > > Thanks for the report and the suggestion; I've been bitten few times by > > this bug myself, so I agree it's time to fix it. See the attached > > minimalistic patch, which I'll push to maint in a few days (as usual, > > reviews welcome). There is also a follow-up patch (attached as well) > > that ensures the stub rules do not end up covering real errors. > > What happens if I write > include fragment-with-typo-in-name.am > > but I want that fragment included? > I fear I cannot parse this question... Do you mean that you want to include the file `bar.am' but erronously write "include baz.am" in your Makefile.am instead? In this case, automake will obviously complain and bail out, as it did before my patch (in fact, said patch doesn't touch the automake script at all, so this invariance of its behaviour should be obvious). > IIUC then automake will still error out when it gets rerun, but > because of the way dependencies are handled now, it won't get rerun > automatically, right? > Why not? If you change `Makefile.am', the automake-generated makefiles will know that they have to rebuild the corresponding `Makefile.in', so they'll invoke automake -- which will dutifully fail if any file included by the `Makefile.am' does not exist. See also the new `deleted-am.test' test script in my second patch, which should check this behaviour. But all of this seems pretty obvious (unless I'm missing something really fundamental), so I think I must be misunderstanding your questions/doubts here... Regards, Stefano
