llvm dev - Jul 2021 - Clang-12 fails build on MacOS

It appears that the proposed workaround had been tested and proven to work. 

Which is why I'm asking to give it a try. 

Perhaps doing that would help understanding the root cause too.

Regards,
Uri
> On Jul 18, 2021, at 14:27, Raul Tambre <raul at tambre.ee> wrote:
> 
> Thanks for the info, however I don't think we still understand the
root cause. Why do we end up with two instances trying to create the symlink to
the same location?
> 
> Per my thinking different targets end up with separate build directories
thus this shouldn't happen. And since the different runtime builds are
sub-builds your proposed dependency tracking solution wouldn't work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5819 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210718/59a80cce/attachment.bin>

Darwin build is a bit different from other build. I would look for a fix that
avoid that race conditions rather than hard code targets.

Also I don’t know what you mean by giving the workaround a try. The initial
workaround I provide is about altering build configuration which is mostly on
the user unless you are using the cmake cache in the repo. We also never hit
that problem on our side since we always build with ninja and it appears ninja
doesn’t schedule the copy close to each other.

Steven 
> On Jul 18, 2021, at 11:32 AM, Blumenthal, Uri - 0553 - MITLL <uri at
ll.mit.edu> wrote:
> 
> It appears that the proposed workaround had been tested and proven to
work.
> 
> Which is why I'm asking to give it a try. 
> 
> Perhaps doing that would help understanding the root cause too.
> 
> Regards,
> Uri
> 
>> On Jul 18, 2021, at 14:27, Raul Tambre <raul at tambre.ee> wrote:
>> 
>> Thanks for the info, however I don't think we still understand the
root cause. Why do we end up with two instances trying to create the symlink to
the same location?
>> 
>> Per my thinking different targets end up with separate build
directories thus this shouldn't happen. And since the different runtime
builds are sub-builds your proposed dependency tracking solution wouldn't
work.