<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Menlo;
panose-1:2 11 6 9 3 8 4 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
font-size:12.0pt;
font-family:Menlo;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Menlo;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoPlainText>On 7/18/21, 17:01, "Steven Wu" <stevenwu@apple.com> wrote:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> Darwin build is a bit different from other build.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Yes. But it is still defined in what Macports considers “upstream”, aka – you guys. Which is why I’m bringing this issue here.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> I would look for a fix that avoid that race conditions rather than hard code targets.<o:p></o:p></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>Adding an explicit separate target via “add_custom_target()” eliminates the race conditions.<o:p></o:p></span></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> Also I don’t know what you mean by giving the workaround a try.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I mean – incorporate that solution and confirm for yourself that it works.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> The initial workaround I provide is about altering build configuration<o:p></o:p></p><p class=MsoPlainText>> which is mostly on the user unless you are using the cmake cache in the<o:p></o:p></p><p class=MsoPlainText>> repo. We also never hit that problem on our side since we always build<o:p></o:p></p><p class=MsoPlainText>> with ninja and it appears ninja doesn’t schedule the copy close to each other.<o:p></o:p></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>Well, with Macports we do not have the luxiry of building with ninja. So, for us it has to stay with CMake.<o:p></o:p></span></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText><span style='color:black'>I rather doubt that the workaround you suggested (which kills Apple M1 builds, if I recall correctly) would be acceptable for Macports, whose goal is to successfully build and run for Intel and M1 platforms.<o:p></o:p></span></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p><p class=MsoPlainText> > On Jul 18, 2021, at 11:32 AM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:<o:p></o:p></p><p class=MsoPlainText> > <o:p></o:p></p><p class=MsoPlainText> > It appears that the proposed workaround had been tested and proven to work. <o:p></o:p></p><p class=MsoPlainText> > <o:p></o:p></p><p class=MsoPlainText> > Which is why I'm asking to give it a try. <o:p></o:p></p><p class=MsoPlainText> > <o:p></o:p></p><p class=MsoPlainText> > Perhaps doing that would help understanding the root cause too.<o:p></o:p></p><p class=MsoPlainText> > <o:p></o:p></p><p class=MsoPlainText> > Regards,<o:p></o:p></p><p class=MsoPlainText> > Uri<o:p></o:p></p><p class=MsoPlainText> > <o:p></o:p></p><p class=MsoPlainText> >> On Jul 18, 2021, at 14:27, Raul Tambre <raul@tambre.ee> wrote:<o:p></o:p></p><p class=MsoPlainText> >> <o:p></o:p></p><p class=MsoPlainText> >> 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?<o:p></o:p></p><p class=MsoPlainText> >> <o:p></o:p></p><p class=MsoPlainText> >> 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.<o:p></o:p></p></div></body></html>