[Openmp-commits] [Openmp-dev] Large Refactor of CMake build system
hfinkel at anl.gov
Tue Jul 21 17:32:05 PDT 2015
----- Original Message -----
> From: "C Bergström" <cbergstrom at pathscale.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: openmp-commits at dcs-maillist2.engr.illinois.edu, openmp-dev at dcs-maillist2.engr.illinois.edu, "Hans Wennborg"
> <hans at chromium.org>
> Sent: Tuesday, July 21, 2015 7:16:46 PM
> Subject: Re: [Openmp-commits] [Openmp-dev] Large Refactor of CMake build system
> On Wed, Jul 22, 2015 at 6:50 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> > ----- Original Message -----
> >> From: "C Bergström" <cbergstrom at pathscale.com>
> >> To: "Hal Finkel" <hfinkel at anl.gov>
> >> Cc: openmp-commits at dcs-maillist2.engr.illinois.edu,
> >> openmp-dev at dcs-maillist2.engr.illinois.edu, "Hans Wennborg"
> >> <hans at chromium.org>
> >> Sent: Tuesday, July 21, 2015 6:31:58 PM
> >> Subject: Re: [Openmp-commits] [Openmp-dev] Large Refactor of CMake
> >> build system
> >> >> >
> >> >> > -Hal
> >> >>
> >> >> Ok - so standalone user hitting a critical blocking issue isn't
> >> >> important enough feedback to consider this a blocker.
> >> >>
> >> >> I didn't say revert the whole thing - I said leave it out of
> >> >> the
> >> >> "STABLE" 3.7 branch.
> >> >
> >> > The stable branch is not yet stable, it is stabilizing. It was,
> >> > after all, forked from trunk not long ago. We're now going
> >> > through
> >> > the process of isolating and fixing bugs. This is how the system
> >> > works, and your feedback is part of that process.
> >> I thought the branch was tagged and "final". Maybe I'm mistaken on
> >> this process since I'm not typically involved with the main
> >> clang/llvm
> >> release process.
> > Ah, no. We've tagged the release branch, but we then draw release
> > candidates from that branch. If you look in the box labeled at
> > 'Upcoming Releases' on the front page of http://llvm.org/, you'll
> > see the current target schedule:
> > 14 July 2015: Branch for 3.7.0 release
> > 14 July–21 July: Testing Phase I
> > 22 July–29 July: Fix bugs from Testing Phase I
> > 30 July–6 August: Testing Phase II
> > 7 August–14 August: Fix bugs from Testing Phase II
> > 21 August: Release LLVM 3.7.0.
> > As release candidates are made, and fixes are produced, they're
> > merged into the release branch.
> >> Until now - we have had no plans to maintain a fork. I've been
> >> solely
> >> focused on getting all changes upstream and doing production
> >> releases
> >> directly off the main repo. (Either stable branch or master)
> >> In fact I'm surprised and discouraged to hear about patches which
> >> aren't going upstream. So far there hasn't been any untenable
> >> technical reason to not contribute it from our side. I'd be very
> >> interested to know what patches you're maintaining separately and
> >> why.
> > These are patches to integrate Clang/LLVM with libraries and
> > directory layouts that are only provided as part of the relevant
> > bundle of software. All of bgclang is open source, however, and if
> > there is something in there you feel should be upstream, and
> > isn't, we should work on changing that. My TODO list in this area
> > is not empty.
> >> ---------
> >> If someone doesn't push the #if PathScale change - then I'll send
> >> a
> >> patch in the next day or so. I expect it to be trivial. That's the
> >> best middle ground I can hope for in the short term.
> > Sounds good; we have plenty of time to fix things before the actual
> > release.
> #1 I don't think a "large refactor of cmake build system" should be
> merged 2 days after the branch was cut. It really should only be for
> bug fixes from what I can see
We need to start filtering at some point, but from the standpoint of moving the whole community forward, having this in 3.7 is the right decision. Now that Clang has completed its OpenMP 3.1 implementation, users are going to try building this OpenMP runtime library for use with Clang/LLVM. We want them to gain experience, and give us feedback on, the this build system, not the old one that needed replacement. Also, we knew this was coming for a long time, so it was a surprise to no one following the list. This is obviously a judgment call, but merging this a couple of days after the branch seems worth it. That still gives us over a month to find/fix bugs, and only a couple of days less than we have to do the same for the whole rest of the project.
> #2 I need to look more into how you're packaging stuff - the cmake
> pieces I plan to open source may help with some of that. I remember
> some of your patches in the past clobbered normal Power7 support and
> hopefully that stuff is resolved. If it's just to do with directory
> structures I certainly think I can help. (sode note - I owe you an
> update for mira/vesta - coming soon)
Sure, sounds good. My patchsets should now be clean re: clobbering other PowerPC things. Let's discuss this off-list.
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the Openmp-commits