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

[C Bergström]

On Wed, Jul 22, 2015 at 7:32 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 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.

IMNSHO

Users should not be building this library. This should be shipped with
the packaged compiler they are getting. Further, the packagers decide
what's the default and nothing prevented them from doing that in the
recent past.

>From a developer perspective changing the default probably has no or
little impact on them. There's not a lot of people who are really
working on OpenMP runtimes. (Short list of companies and research
groups) That list gets even shorter when it comes to people using
*this* library.