bug#7884: [PATCH] yacc: fix VPATH builds with FreeBSD make

[Ralf Wildenhues]

* Stefano Lattarini wrote on Fri, Jan 28, 2011 at 01:51:40PM CET:
> On Thursday 27 January 2011, Ralf Wildenhues wrote:
> > Does 'make -n' create files (for any target)?
> >
> No, and I've updated the `yaccdry.test' testcase to also check for this
> (see attached amended patch).

Thanks.

> > How do you ensure in your patch that 'make distdir' does not create files?
> >
> Well, it does, but I don't see any problem with this.

Ah, you're right.  I was confused here.

> > How do you ensure in your patch that 'make clean' does not create files?
> >
> In fact, it does (good catch, BTW); see new testcase in the attached patch.
> Yes, this is clearly a wart, but a minor one, and having it is IMHO a price
> worth paying in order to have VPATH builds work on FreeBSD.

Wait.  When you do '../configure && make clean', then your code creates
the files just before removing them again, no?  That is what I meant.
It is not a disqualifying problem that it does so, but it is not nice.

It becomes more of a problem when things like
  make tags
  make some-arbitrary-user-target

start creating files that they shouldn't have anything to do with.
OTOH,
  make some-prog-that-depends-on-yacc-output

should be built with updated yacc outputs.

> BTW, if you decide to get rid of said wart in a follow-up patch, that can
> probably be done using the FreeBSD make special variable `.TARGETS' (akin
> to GNU make's `MAKECMDGOALS').

I suppose, yes.

Another problem, which might be more serious:

Say I checkout a git tree of my project, do a VPATH build from it on
FreeBSD.  The next day someone has updated foo.y in git, I pull the new
version, type 'make' again inside the old build tree.  This fails to use
the code from the new foo.y code version (because at the time the .BEGIN
rule was invoked, the old $(srcdir)/foo.c was still in place).

I use such setups regularly.  I know they break when the source tree
changes are large, but still, with no source tree graph changes it is a
subtle failure that developers will rightly blame Automake for.  It can
be fixed by comparing time stamps, at the cost of now getting into the
time stamp business that I mentioned earlier.

Then, there is the issue of which make implementations support the
.TARGETS feature.  What if GNU make 3.84 starts supporting it?
Our makefiles then would suddenly cause regressions for GNU make users.

I guess my point is, I fear that your approach is fundamentally not
robust.  I acknowledge that BUILT_SOURCES is not robust either
($(BUILT_SOURCES) being updated routinely as part of 'all', 'check',
'install', but no other special targets).  But at least with dependency
tracking enabled, BUILT_SOURCES is typically needed only the first time
'make' is used in some build tree.

Cheers,
Ralf