[Openmp-commits] [Openmp-dev] Large Refactor of CMake build system
cbergstrom at pathscale.com
Tue Jul 21 17:16:46 PDT 2015
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
>> 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
> 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
#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)
More information about the Openmp-commits