[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 5:41:55 PM
> Subject: Re: [Openmp-commits] [Openmp-dev] Large Refactor of CMake build system
> 
> > I don't believe that your problem is imaginary, but we also need to
> > be able to reproduce it, or have a patch fixing it with some
> > explanation of what's going on. Regardless, it is really important
> > for the LLVM community to move forward with the new build system.
> > We certainly have a release-candidate process, and the purpose of
> > this process is to isolate and correct bugs. In that sense, the
> > system is working as intended. The new CMake build system is in
> > line with LLVM's general best practices, and the community has
> > demanded that as a prerequisite for moving forward with
> > integration with Clang. As a result, we really do need to get user
> > feedback on this build system as opposed to any other.
> >
> >  -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.

> -----------
> Everyone here is totally cool with this difficult to reproduce bug
> that was introduced in the stable branch at the last minute.
> (Actually
> days after the tagged release)

We tagged the branch, we did not have a release candidate until much later.

> 
> If that's the way this project will work well then I guess my
> feedback
> and effort isn't worth shit. It would be far less effort for us to
> fork than waste my time and yours.
> 
> We don't hit this issue in any other project (libc++, compiler-rt or
> others). So clearly the openmp cmake is doing something different
> from
> those.
> --------
> To stop wasting time on this - I see the following options and I let
> Hans or someone else in a leadership position decide
> 
> 1) We fork off - going forward I will have nothing to do with this
> project
> 
> 2) revert the offending changes in the 3.7 release branch (preferred)
> 
> 3) introduce a fix asap (unlikely since the root problem hasn't been
> identified)
> 
> 4) Introduce #if PathScale logic in the cmake files to avoid setting
> any flags when our compiler it detected. (2nd preference) The patch
> for this should be trivial and if things are designed correctly
> should
> take less time than the average email in this thread. I see there's
> logic for Intel compiler and others already. I don't like the
> spaghetti mess, but c'est la vie

Frankly, I don't understand your position. You ship a product based, in part, on LLVM software. So do I. I certainly have patches that I apply to the upstream sources to deal with build/environment customizations that, for several different reasons, are not appropriate for the upstream repository. Nevertheless, I don't view that as being in conflict with contributing to the community. You can clearly do whatever you need to in order to fix this problem locally. If the problem turns out to be a problem with the upstream build system, clearly we'll act to correct it. Right now, we don't have enough information to act in that regard.

We appreciate your feedback, and we're well aware that testing during the release cycle takes time and effort on everyone's part.

 -Hal

> 

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