[Openmp-dev] [PATCH] [Revisedx2] Initial cmake support

Jack Howarth howarth.mailing.lists at gmail.com
Mon Jun 2 10:39:24 PDT 2014


Jonathan,
      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
llvm.org. In any case, the main changes that I implemented compared to the
legacy cmake files on the openmprtl site are listed in...

http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-June/000154.html

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).
         Jack

On Mon, Jun 2, 2014 at 12:59 PM, Peyton, Jonathan L <
jonathan.l.peyton at intel.com> wrote:

>  Hello All,
>
>
>
> I have been here at Intel working on an ‘exact’ translation of the
> build.pl build system to an identical CMake build system (without the
> build.pl Perl wraparound of course).  I’ve looked at the recently added
> CMake build system and appreciate the work you all have done.  The system
>
> 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 build.pl system for both Mac and Linux using clang, gcc,
> or icc.
>
> 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.
>
>
>
> I’d be happy to answer any questions regarding the new CMake build system.
>
>
>
> Thanks,
>
> Johnny
>
>
>
> *From:* openmp-dev-bounces at cs.uiuc.edu [mailto:
> openmp-dev-bounces at cs.uiuc.edu] *On Behalf Of *Jack Howarth
> *Sent:* Monday, June 2, 2014 11:14 AM
> *To:* Andrey Bokhanko
> *Cc:* openmp-dev at dcs-maillist2.engr.illinois.edu; David Chisnall
>
> *Subject:* Re: [Openmp-dev] [PATCH] [Revisedx2] Initial cmake support
>
>
>
> Andrey,
>
>      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.
>
>            Jack
>
>
>
>
>
> On Mon, Jun 2, 2014 at 11:48 AM, Jack Howarth <
> howarth.mailing.lists at gmail.com> wrote:
>
>  Andrey,
>
>     Reading through the the thread at
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140519/106158.html,
> 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.
>
>             Jack
>
>
>
> On Mon, Jun 2, 2014 at 11:17 AM, Andrey Bokhanko <andreybokhanko at gmail.com>
> wrote:
>
>   Alp,
>
> With all respect, a few of assertions you made are simply *not true*.
>
>
>
> On Mon, Jun 2, 2014 at 6:02 PM, Alp Toker <alp at nuanti.com> wrote:
>
> 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.
>
>
>
> What "discussions... that go back weeks" you are speaking about?!
>
> Jack started his "On Improving the Build System revisited" thread on May
> 30. This is four days ago, not weeks.
>
> 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.
>
>
>
> 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.
>
>
>
> What timescales you are speaking about?!
>
>
> 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.
>
>
> 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?
>
>
>
> That's *exactly* what we did back in March.
>
> http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-March/000055.html
>
> Yours,
> Andrey
>
>
>
>
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at dcs-maillist2.engr.illinois.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20140602/ec6117cc/attachment.html>


More information about the Openmp-dev mailing list