[Openmp-dev] [Openmp-commits] Large Refactor of CMake build system

[Hal Finkel]

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

 -Hal

> 
> Thanks
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory