bug#17614: parallel compilation fails

[Peter Johansson]

Hi Mike,

On 25/1/22 16:24, Mike Frysinger wrote:
> On 19 Jan 2022 18:32, Peter Johansson wrote:
> > On 19/1/22 18:10, Mike Frysinger wrote:
> > > assuming it still fails with Automake 1.16 ...
> >
> > I'll test when I'm out of this semi-lockdown and have access to a
> > computer with more CPUs.
> >
> > > can you link to the project for us to take a look ?
> > Tar file is available from here
> >
> > https://sourceforge.net/projects/libyat/
> >
> > and subversion repo from here if that's preferable
> >
> > https://dev.thep.lu.se/yat/svn/trunk
> i grabbed the 0.19 release.  perhaps unsurprising, nothing stood out to me
> related to the error above.  you didn't have any recursive makes or any code
> that seemed to override the dep generation or create conflicting outputs.
>
> if you can reproduce it, get a full log and send it over, and include the
> config.log file i think.  something like `make -O -j... >& log`.
>
> the error you quoted is part of automake's dependency generation.  it's very
> weird that you'd get an error about .Tpo & .Plo being the same file when the
> rule that creates them creates the .Tpo then moves it to .Plo.  there is no
> place where we ever write to .Plo otherwise.

I've tried this now and in short I cannot reproduce it. I tried with 
Automake 1.13 now (bcs it's what available by default) and ran both on 
current code and an older branch, but nothing that looks like this. Many 
things have changed since 2014 when this was filed and I think for 
example that the file system was much slower back then. I suspect that 
the problem was that the same file was compiled twice, but since I can't 
reproduce it, it's impossible to determine whether it was due to 
problematic Makefile.am, generated Makefile, or possibly behaviour of 
make, so if not already closed, please close this and I'll report back 
if something similar returns.

Cheers,

Peter