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

[Hans Wennborg]

On Tue, Jul 21, 2015 at 11:20 AM, C Bergström <cbergstrom at pathscale.com> wrote:
> My observation is that it's not consistently working and that's why
> I'm even more upset and nervous about this change.
>
> Further, "it works for me" is a very bad reason to go screw up a
> stable branch and to continue to advocate that it so strongly.

I've tried to reproduce the problem described here by hacking up a
local clang that doesn't support the -static-libgcc flag. I verified
that the cmake correctly identifies that the flag is not supported,
that it's not used during the build, and doesn't show up in the build
file (it would show in build/runtime/src/CMakeFiles/omp.dir/link.txt
if supported). I also didn't see anything wrong in the cmake file.

I'm sympathetic to your build issue, but I do think the onus is on you
to show that something is broken here in a way that the community can
reproduce or at least understand.

> The reason the release branch (before the merge commits) "works for
> me" is because we have a wrapper cmake around the the project which
> sets things correctly.
> -------------
> Here's what I see
>
> From cmake # Everything would appear to look good, right? (Also know
> that it says g++, but in fact it's really pathcc.. I don't quite
> understand that)
> -------------------
> checking whether we are using the GNU C++ compiler... yes
> checking whether /opt/ekopath/bin/pathCC accepts -g... yes
> checking whether g++ accepts -static-libstdc++ -static-libgcc... no
> checking for gnatbind... no

The above looks like output from a configure script, not CMake.
Where's that coming from?

 - Hans