<div dir="ltr">Jonathan,<div> Thanks for the update. We had no idea that this work was in progress. It is unfortunate that an openmp repository at Intel (like that for clang-omp) doesn't exist to monitor such work before it is submitted to <a href="http://llvm.org">llvm.org</a>. In any case, the main changes that I implemented compared to the legacy cmake files on the openmprtl site are listed in...<br>
<div class="gmail_extra"><br><a href="http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-June/000154.html">http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-June/000154.html</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">
I actually have darwin9 powerpc machine with our fink llvm34-3.4.1 packaging installed (that contains a merge of the current clang-omp branch changes applied onto the 3.4.1 release). If you could shared your proposed CMakeList.txt changes for openmp on list, I would be happy to report back if the powerpc support works on this ancient target (its the only non-intel machine I have access to).</div>
<div class="gmail_extra"> Jack</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 12:59 PM, Peyton, Jonathan L <span dir="ltr"><<a href="mailto:jonathan.l.peyton@intel.com" target="_blank">jonathan.l.peyton@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Hello All,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I have been here at Intel working on an ‘exact’ translation of the <a href="http://build.pl" target="_blank">build.pl</a> build system to an identical CMake build system (without the <a href="http://build.pl" target="_blank">build.pl</a> Perl wraparound
of course). I’ve looked at the recently added CMake build system and appreciate the work you all have done. The system<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I’ve created has Windows support, Fortran support, Mac Fat Library support, Intel-specific header creation support, Intel MIC support as well as mirroring the
<a href="http://build.pl" target="_blank">build.pl</a> system for both Mac and Linux using clang, gcc, or icc.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">All build types (release, debug) and library types (stubs, normal) are supported as well. This build system is currently going through the review process and
should be done very soon.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I’d be happy to answer any questions regarding the new CMake build system.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Johnny<u></u><u></u></span></p>
<p class="MsoNormal"><a name="1465d86148d7a407__MailEndCompose"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></a></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> <a href="mailto:openmp-dev-bounces@cs.uiuc.edu" target="_blank">openmp-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:openmp-dev-bounces@cs.uiuc.edu" target="_blank">openmp-dev-bounces@cs.uiuc.edu</a>]
<b>On Behalf Of </b>Jack Howarth<br>
<b>Sent:</b> Monday, June 2, 2014 11:14 AM<br>
<b>To:</b> Andrey Bokhanko<br>
<b>Cc:</b> <a href="mailto:openmp-dev@dcs-maillist2.engr.illinois.edu" target="_blank">openmp-dev@dcs-maillist2.engr.illinois.edu</a>; David Chisnall</span></p><div class=""><br>
<b>Subject:</b> Re: [Openmp-dev] [PATCH] [Revisedx2] Initial cmake support<u></u><u></u></div><p></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Andrey,<u></u><u></u></p><div><div class="h5">
<div>
<p class="MsoNormal"> Also, note that when I say a single set of patches, I don't mean a single patch but number individual patches submitted as a complete patch set. After many years of carefully monitoring merges in FSF gcc (and helping mitigate the breakage
from them on the darwin targets since Apple abandoned gcc), it has become clear that there are certain social pressures in the review process that a unified patch set creates. When a complete set of patches are submitted and say 90% of them are quickly reviewed,
approved and committed, this results in a social pressure for the remaining reviewers to accelerate their work so as to not be seen as retarding the merge.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> Jack<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div><div><div class="h5">
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Jun 2, 2014 at 11:48 AM, Jack Howarth <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<p class="MsoNormal">Andrey,<u></u><u></u></p>
<div>
<p class="MsoNormal"> Reading through the the thread at <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140519/106158.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140519/106158.html</a>, I can understand
the sensitivities here on the topic of reviews. IMHO, the process of integrating clang-omp and openmp into the standard llvm/compiler-rt/clang build would go much smoother if the merge of clang-omp changes were sent up stream as a cohesive set of patches to
merge the branch like FSF gcc does. I know this will set the hair on edge for some of the llvm developers, but when a merge is submitted as a single set of patches, the upstream developers are forced to take the review process far more seriously. Especially,
if the reviews are coming in slowly, submitting these patches upstream in a piecemeal approach will only aggravate the problem of timely reviews.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:rgb(136,136,136)"> Jack<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Mon, Jun 2, 2014 at 11:17 AM, Andrey Bokhanko <<a href="mailto:andreybokhanko@gmail.com" target="_blank">andreybokhanko@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
</div>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Alp,<u></u><u></u></p>
</div>
<p class="MsoNormal">With all respect, a few of assertions you made are simply *not true*.<u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Jun 2, 2014 at 6:02 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<p class="MsoNormal">It should be made clear that the current OpenMP runtime CMake build system has been in development for some time, including on-list discussions in the LLVM community that go back weeks following all the best practices we have. The only
thing that changed is that C. Bergstrom graciously provided the sign-off we needed to integrate Jack's work late last week.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal">What "discussions... that go back weeks" you are speaking about?!<br>
<br>
Jack started his "On Improving the Build System revisited" thread on May 30. This is four days ago, not weeks.<br>
<br>
And since when "all the best practices" include introducing a new build system without getting project architect's consent? -- especially after explicitly asked to do so, a message that you conveniently ignored.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<p class="MsoNormal">So it's a mischaracterisation to say this happened over the weekend. Even if it did that would be on the long side compared to timescales seen on llvm-commits.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal">What timescales you are speaking about?!<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><br>
For reference, we wait for *weeks* for our OpenMP in clang patches to be reviewed! And we commit them *only* after explicit consent of one of clang code owners -- even if we already got code review from someone else.<br>
<u></u><u></u></p>
</div>
<div>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<p class="MsoNormal">In general it's a good idea to participate in on-list discussions and give a heads up if you see people discussing features you have plans for. Is there anything else in the pipeline?<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">That's *exactly* what we did back in March.<br>
<br>
<a href="http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-March/000055.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-March/000055.html</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Yours,<br>
Andrey<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">_______________________________________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@dcs-maillist2.engr.illinois.edu" target="_blank">Openmp-dev@dcs-maillist2.engr.illinois.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</blockquote></div><br></div></div></div>