On Wednesday 19 October 2011, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Mon, Oct 17, 2011 at 10:20:05AM CEST:
> > On Sunday 16 October 2011, Ralf Wildenhues wrote:
> > > 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).
> 
> Alright.  The first time you write the include line and invoke automake,
> it will bail out if there is a typo.
>
Yes.

> But if the fragment file is later (re)moved, and you type 'make' again,
> you will not get an error, as automake will not be rerun automatically.
>
Hmm... but `Makefile.in' depends on the included file that has just been
removed, so `make' will try to rebuild this file -- and after my patch
this will be a no-op, due to the new stub rules -- and will then try to
rebuild `Makefile.in' by invoking `automake' -- which will fail due to
the missing include file.

> Only when automake is invoked manually, or triggered by some other
> out of date file, will the error be noticed.
>
This is not true; and in fact, I've added a new test case to ensure
we don't regress in this regard (see `deleted-am.test').

> Taken a step further, if some fragment file for some reason does not
> get included in a release tarball, then the developer might not see
> that during testing,
>
This shouldn't be a serious problem, since Automake takes care of
automatically distributing included `.am' files.  But even if the
dist tarball gets messed up in strage ways, and some `.am' files get
removed from it, the same reasoning given above should apply, so the
error will be caught.

Still, it would be nice to have a testcase for this (as well as for the
sister situations with included `.m4' files).  So I'd like to queue the
attached patch as well.

[NOTE: while writing this patch, I've hit another automake bug/limitation,
       that I will report in a new thread soonish].

> but users will miss a file needed to tinker with the package.
> 
> Am I missing something?
> 
I hope so :-) -- otherwise I've completely misunderstood something
cardinal here.

Thanks,
  Stefano