[Openmp-commits] [Openmp-dev] 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 7:42:12 PM
> Subject: Re: [Openmp-commits] [Openmp-dev] Large Refactor of CMake build system
> 
> 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.
> 

In this case, "users" of the OpenMP build system means exactly those people who build it. Some of these are end users, some are packagers, some are its developers. It is these people from whom we need, and will, get feedback on the build system. From the developers we'll get feedback regardless, granted, but from the other groups it should be in the release.

 -Hal


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