<div dir="ltr">I've had time to check, and a large amount of my concerns over the openmp CMake build have not been addressed.<br><div><br></div><div>For example, it defines at global scope a reasonably large number of variables like "os", "arch" and friends.</div><div><br></div><div>Another example is that it uses a completely novel way of managing compiler flags compared to all of LLVM, Clang, CompilerRT, libc++, and libc++abi. I have to think that even if some of these don't apply, at least one does. In particular, the openmp runtime seems to have almost identical needs for configuration as the libc++ runtime library, with the possible exception of needing to run an assembler.</div><div><br></div><div>I also don't see any way to run any of the OpenMP tests using the CMake build, but maybe I'm just missing it.</div><div><br></div><div>I'll repeat what I said previously in the other thread: I think that the OpenMP CMake build should be replaced with one that functions essentially the same way as the libc++ CMake build, including the use of 'lit' to drive the test suite. libc++ has extremely similar build configuration and testsuite needs, and so I feel like we shouldn't have two radically different ways of doing everything within the same project. It makes the maintenance burden for those of us that work on the larger LLVM project's CMake support much, much higher. Perhaps a detailed explanation of why that isn't feasible or reasonable?</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 11, 2015 at 8:45 PM Jack Howarth <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Richard,<br>
I do my local build using tarballs generated from current trunk<br>
svn pulls. The rough formula I use (after these are extracted) are...<br>
<br>
cd llvm-3.7.0.src<br>
mv ../cfe-3.7.0.src tools/clang<br>
mv ../compiler-rt-3.7.0.src projects/compiler-rt<br>
mv ../libcxx-3.7.0.src projects/libcxx<br>
mv ../openmp-3.7.0.src projects/openmp<br>
mv ../polly-3.7.0.src tools/polly<br>
mv ../clang-tools-extra-3.7.0.src tools/clang/tools/extra<br>
mkdir build<br>
cd build<br>
cmake -DLLVM_BUILD_32_BITS:BOOL=OFF -DLLVM_TARGETS_TO_BUILD=X86 \<br>
-DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_BUILD_TYPE=Release<br>
-DLIBOMP_OSX_ARCHITECTURES="x86_64;i386" \<br>
-DCMAKE_OSX_SYSROOT:STRING=/<br>
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" \<br>
-DLLVM_ENABLE_LIBCXX=ON -DLIBCXX_LIBCPPABI_VERSION=""<br>
-DENABLE_CLANG_OPENMP=ON ..<br>
make VERBOSE=1<br>
<br>
This builds the libomp.dylib as a fat binary on x86_64 darwin (for<br>
both i386/x86_64 support).<br>
I always execute "perl -pi -e 's|libgomp|libomp|g' CMakeLists.txt" in<br>
tools/clang before the build to<br>
switch the -fopenmp default to libomp.<br>
Jack<br>
<br>
On Thu, Jun 11, 2015 at 10:34 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br>
> On Thu, Jun 11, 2015 at 7:26 PM, Jack Howarth<br>
> <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jun 11, 2015 at 9:34 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><br>
>> wrote:<br>
>> > On Thu, Jun 11, 2015 at 4:58 PM, Jack Howarth<br>
>> > <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Chandler,<br>
>> >> It has been over 10 days with no response (3 more than you used<br>
>> >> to justify reverting the libiomp5 default for -fopenmp). What blockers<br>
>> >> remain in current cfe/openmp svn which would prevent the default for<br>
>> >> -fopenmp from being switched over to libomp?<br>
>> ><br>
>> ><br>
>> > From my prior email these were the steps:<br>
>> ><br>
>> > "1) Reach the point where the openmp runtime library can be checked out<br>
>> > into<br>
>> > a normal llvm / clang build tree (into projects/openmp, perhaps) and it<br>
>> > integrates properly into the build and builds successfully on various<br>
>> > systems.<br>
>> > 2) Update the clang "getting started" documentation to suggest doing<br>
>> > this if<br>
>> > the user wants OpenMP support<br>
>> > (changehttp://<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_get-5Fstarted.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=uMFgfFcbIL2iicSfA8LaPtX-fEhw2nzEclUI8g6nNmA&s=lbxJodaOH62qYvylXNd4hthon0pgdhtR3C1MraDqIc0&e=" rel="noreferrer" target="_blank">clang.llvm.org/get_started.html</a><br>
>> > to say what to check out and where -- no steps other than an 'svn co'<br>
>> > should<br>
>> > be necessary).<br>
>> > 3) Change the default for CLANG_DEFAULT_OPENMP_RUNTIME to libomp<br>
>> > (possibly<br>
>> > conditioned on a "is libomp part of this build?" test)."<br>
>> ><br>
>> > Step 2 has certainly not happened. Has step 1 happened?<br>
>><br>
>> I have been building current openmp in the llvm/projects/openmp<br>
>> location as a cmake<br>
>> build on x86_64-apple-darwin14 daily without issues. So step 1 is<br>
>> complete on darwin.<br>
><br>
><br>
> If you can let me know what I should check out where, I'll be happy to test<br>
> it on Linux for you. (Should I check out<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_svn_llvm-2Dproject_openmp_trunk_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=uMFgfFcbIL2iicSfA8LaPtX-fEhw2nzEclUI8g6nNmA&s=oGYj5_zsUgjKStuHExoy1AeKxHK03va1QSDCuXLwbYc&e=" rel="noreferrer" target="_blank">http://llvm.org/svn/llvm-project/openmp/trunk/</a> or just the runtime/<br>
> subdirectory there?)<br>
><br>
> It looks like the openmp directory is not listed in llvm's<br>
> projects/CMakeLists.txt, so there may be some more integration work required<br>
> for this to integrate properly into the llvm/clang build.<br>
><br>
>> >> Jack<br>
>> >><br>
>> >> On Mon, Jun 1, 2015 at 7:34 AM, Jack Howarth<br>
>> >> <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>> >> > Chandler,<br>
>> >> > Now that openmp trunk is producing the desired renamed libomp<br>
>> >> > shared library by default and a libgomp symlink to it for use by<br>
>> >> > -fopenmp=libgomp, do you have any remaining objections to switching<br>
>> >> > CLANG_DEFAULT_OPENMP_RUNTIME from libgomp to libomp?<br>
>> >> > Jack<br>
>> >> > ps As the recent posting in cfe-commits indicates....<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150525/130067.html" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150525/130067.html</a><br>
>> >> ><br>
>> >> > the absence of complaints about the previous -fopenmp=libgomp default<br>
>> >> > may be more due to misconceptions about the level of support for<br>
>> >> > OpenMP that provides rather than any real desire to use it in place<br>
>> >> > of<br>
>> >> > the LLVM openmp (which is completely functional).<br>
>> >> _______________________________________________<br>
>> >> cfe-dev mailing list<br>
>> >> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> ><br>
>> ><br>
><br>
><br>
</blockquote></div>