[Openmp-dev] Large Refactor of CMake build system

[Hans Wennborg]

+Jonathan

On Mon, Jul 20, 2015 at 12:02 PM, C Bergström <cbergstrom at pathscale.com> wrote:
> This "discussion" was posted to -commits and not here - (which is not
> cool for something this size)
> --------------
>
> Original thread - sorry for messed up indenting
> Hi Jonathan,
>
> I think this is a reasonable request as we're still early in the
> process and this can be considered a fix towards completing an
> existing feature.
>
> I've merged this and the follow-up commit in r242335 and r242336, respectively.
>
> Thanks,
> Hans
>
> On Wed, Jul 15, 2015 at 2:29 PM, Peyton, Jonathan L
> <jonathan.l.peyton at intel.com> wrote:
>> Hans,
>>
>> We were trying to get this into the 3.7.0 release so users could have this library be the default for the -fopenmp flag.  We missed the deadline by one day.  There were two commits that refactor the CMake code to be up to LLVM standards.  I would greatly appreciate if this (and the follow up commit r242301) were committed to the 3.7.0 openmp branch.  I know they are large, but they are key to getting the LLVM OpenMP Runtime library set as the default for clang.
>>
>> -- Johnny
>
> ----------
>
> This isn't really just about missing the deadline by 1 day. I stayed
> out of the way for you to get the initial cmake changes in and counted
> on doing post-commit testing and review (to clean-up whatever you
> broke). (Chandler was already nitpicking you) This level of change
> wouldn't fly in llvm/clang projects and I hope we can apply the same
> general approach here. Basically it hasn't had any testing outside of
> the Intel world - It would be nice if the Solaris, FreeBSD, Aarch,
> Power8.. etc world had a chance to verify before it's pushed to a
> stable branch. Ths sky won't fall over the -fopenmp flag.
>
> Please revert r242335 and r242336 in the branch and lets move forward
> with testing and bug fixes.

I unfortunately hadn't seen the "Cmake changes" or "Broken cmake logic
after recent changes" threads before doing the merge.

Jonathan, do you have a fix for this? Otherwise it should probably be
reverted from the branch.

 - Hans