bug#10852: VPATH builds cannot recover from missing parser header

[Stefano Lattarini]

On 02/21/2012 11:25 AM, Akim Demaille wrote:
> 
> Le 20 févr. 2012 à 15:23, Akim Demaille a écrit :
> 
>>> But the test is wrong, because it checks that the Yacc-generated .h and .c
>>> files are placed in the $srcdir, while we expect them to be placed in the
>>> $builddir.  Do the tests added by your patch work for you?  They don't work
>>> for me (as I would have expected BTW).
>>
>> OK, so it is my expectations which are wrong.  Probably
>> in an attempt to have simple minded picture in my head,
>> I expected the maintainer source tree to be alike an end
>> user tarball.  Since Automake ships the generated parsers
>> and scanners, I expected it to generate these guys in srcdir,
>> not builddir.
>>
>> So indeed the patch I proposed wanted to exhibit the failure,
>> but it's my understanding that is incorrect.  Hence the test
>> failed, as _I_ expected.
> 
> The more I think about this, the more it troubles me.  It feels
> wrong to me that the maintainer-source-tree is so different from
> the user-source-tree.  It's easy to imagine situations where the
> user, in a vpath-build, would have one parser.c in srcdir and
> another in builddir.  Then, who knows what will happen...
>
The one in builddir should "take precedence", in the spirit of VPATH
builds.

> As I showed in my previous message, it can even behave extremely
> weirdly because of pretty much hidden things, such as the dependencies
> in .deps.
>
This is a real problem, yes.

> Besides, it prevents the maintainers from checking in their generated
> files.
>
Well, saying that the current behaviour *prevents* them from doing so is
a bit of an exaggeration -- they could simply avoid VPATH builds during
development ;-)

> While it is most of the time not right to save them, I do
> know several project that save them, for instance to be
> able to check the diffs between revisions.  Others, such as Bison,
> _must_ save these files.  Whether not to save them under VCS is
> a matter of .gitignore, not of Automake's rules.
>

> It basically boils down to whether the maintainer-src-tree should
> look like a fresh check-out, or a fresh tarball.  I think it should
> look like a tarball.
>
Given your reasoning and concrete use cases, I'm starting to agree that
this might be the most sensible policy.  And something like this is
already being done for '.info' files (see the extensive explanations in
comments in automake.in:handle_texinfo_helper()).

Two points though:

  1. This is a somewhat invasive change IMO; so, if we decide to give
     it a try, we should do so after Automake 1.12 (which I plan
     to release in a couple of weeks, a month tops).

  2. This new policy "maintainer-src-tree should look like fresh tarball"
     should be documented/registered somewhere, preferably with a good
     rationale.

As usual, if someone wants to speed this process up, patches are very
welcome.

> FWIW, Alexandre Duret-Lutz just told me that he was also troubled
> by this.
> 

Thanks,
  Stefano