<div dir="ltr">James,<div> Sorry about that, I assumed that you had signed off on those commits off-list. Concerning the CMakeLists.txt files from <a href="https://github.com/pathscale/openmprtl/tree/master/itt/libomp_oss">https://github.com/pathscale/openmprtl/tree/master/itt/libomp_oss</a>, I tried with those originally but they don't work without additional changes. They also so not produce the same exact build as the 'make compiler=clang' build method. My modified files are a complete reconstruction of their functionality with care taken on both darwin and linux to reproduce the exact behavior of <a href="http://build.pl">build.pl</a> under the cmake system.</div>
<div> Jack</div><div>ps The major changes in my implementation of the cmake files compared to those at openmprtl are...</div><div><br></div><div>1) Addition of the missing…</div><div><br></div><div><div>if(APPLE)</div>
<div> set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -current_version 5.0")</div><div> set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -compatibility_version 5.0")</div><div>
endif()</div></div><div><br></div><div>2) Addition of the missing…</div><div><br></div><div><div>if (NOT APPLE)</div><div> set(FEATURE_FLAGS "${FEATURE_FLAGS} -D KMP_TDATA_GTID")</div><div>endif()</div></div><div>
<br></div><div>to make the cmake build on linux match the <a href="http://build.pl">build.pl</a> one.</div><div><br></div><div>3) Addition of thirdparty/ittnotify/ittnotify_static.c to the SOURCES file list and</div><div>
<br></div><div>set(FEATURE_FLAGS "${FEATURE_FLAGS} -D INTEL_ITTNOTIFY_PREFIX=__kmp_itt_")<br></div><div><div>set(FEATURE_FLAGS "${FEATURE_FLAGS} -D USE_ITT_NOTIFY=1")</div><div>set(FEATURE_FLAGS "${FEATURE_FLAGS} -D INTEL_ITTNOTIFY_PREFIX=__kmp_itt_")</div>
</div><div><br></div><div>to make the cmake build on linux and darwin match the one using <a href="http://build.pl">build.pl</a>. Windows is untested of course.</div><div><br></div><div>4) Addition of kmp_cancel.cpp and kmp_itt.c to SOURCES file list to match the build from <a href="http://build.pl">build.pl</a> on darwin and linux.</div>
<div><br></div><div>5) Removal of kmp_ftn_stdcalls.c from the SOURCES file list as it is not used in the build from <a href="http://build.pl">build.pl</a> on either darwin or linux.</div><div><br></div><div>6) Addition of the missing "-D KMP_ASM_INTRINS" to the add_custom_command for generating z_Linux_asm.o so that behavior of <a href="http://build.pl">build.pl</a> is emulated in cmake. I did this because I noticed that z_Linux_asm.s contained a preprocessor testing this variable.</div>
<div><br></div><div>7) Implemented the use of...</div><div><br></div><div>set(OMP_SHLIBEXT "${CMAKE_SHARED_LIBRARY_SUFFIX}")<br></div><div><br></div><div>to handle the shared library suffix in a generic manner.</div>
<div><br></div><div>8) Added the missing…</div><div><br></div><div><div>set(FEATURE_FLAGS "${FEATURE_FLAGS} -D KMP_USE_ADAPTIVE_LOCKS=1")</div><div>set(FEATURE_FLAGS "${FEATURE_FLAGS} -D KMP_DEBUG_ADAPTIVE_LOCKS=0")</div>
</div><div><br></div><div>for darwin and linux to match the behavior of <a href="http://build.pl">build.pl</a>.</div><div><br></div><div>9) Used…</div><div><br></div><div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -Wno-unused-value")</div>
<div>set(COMMON_FLAGS "${COMMON_FLAGS} -Wno-switch")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -Wno-deprecated-register")</div></div><div><br></div><div>to match the warning flags emitted for "make compiler=clang" by <a href="http://build.pl">build.pl</a> on darwin and linux. </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 6:19 AM, Cownie, James H <span dir="ltr"><<a href="mailto:james.h.cownie@intel.com" target="_blank">james.h.cownie@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OK, sorry, my tone may have been wrong here.<br>
<br>
I am absolutely glad to have people contributing, and certainly don't want to put people off.<br>
(ISTR that I bought Alp at least one beer when we met in London :-)).<br>
<div class="im HOEnZb"><br>
<br>
-- Jim<br>
<br>
James Cownie <<a href="mailto:james.h.cownie@intel.com">james.h.cownie@intel.com</a>><br>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)<br>
Tel: <a href="tel:%2B44%20117%209071438" value="+441179071438">+44 117 9071438</a><br>
<br>
<br>
-----Original Message-----<br>
</div><div class="im HOEnZb">From: David Chisnall [mailto:<a href="mailto:dc552@cam.ac.uk">dc552@cam.ac.uk</a>]<br>
Sent: Monday, June 02, 2014 11:14 AM<br>
To: Cownie, James H<br>
Cc: Alp Toker; Jack Howarth; <a href="mailto:openmp-dev@dcs-maillist2.engr.illinois.edu">openmp-dev@dcs-maillist2.engr.illinois.edu</a>; "C. Bergström"<br>
Subject: Re: [Openmp-dev] [PATCH] [Revisedx2] Initial cmake support<br>
<br>
</div><div class="HOEnZb"><div class="h5">Hi Jim,<br>
<br>
I think there are a few things seriously wrong here.<br>
<br>
On 2 Jun 2014, at 10:50, Cownie, James H <<a href="mailto:james.h.cownie@intel.com">james.h.cownie@intel.com</a>> wrote:<br>
<br>
> * You are moving too fast; all of this has been done since noon on<br>
> Friday here in the UK, and I was out on Friday afternoon and do not<br>
> work at weekends. I have therefore had no chance to look at it before<br>
> it was checked in. (And I'm supposed to be a key reviewer and<br>
> architect here...)<br>
><br>
> * A change like this (which provides a whole new build system) requires more than one review.<br>
<br>
In open source, incremental changes are usually preferred. Adding a new (not-yet-default) built system in response to community need is a good thing, even if it is not perfect.<br>
<br>
> * Since everyone complained so much, we have been working on a CMAKE<br>
> based build system here at Intel that we hope to push this week,<br>
> which *does* support Windows, icc, gcc, clang etc<br>
<br>
That is simply not how open source development works. If you have a private fork that has extensive changes and someone commits something that makes merging them difficult then that is *your problem*, not that of the wider community. This is the fundamental basis of open source development: stuff in the public repository is canonical.<br>
<br>
Developing code in private and then doing big code drops is *not* a good way of interacting with the community. With my hat on as a representative of an operating system that ships clang as the default compiler and would like to see OpenMP work out of the box, I've been following this list and I was not aware that this is something that you were working on.<br>
<br>
Discussions about incorporating a CMake build system date back to 3 March on this list, and I did not find any posts from anyone at Intel indicating that you guys were working on it until your post from today. Indeed, I identified lack of a functional build system as one of the key blockers to portability in my first email to this list.<br>
<br>
> So, at the point when I commit that, I'm going to remove these changes.<br>
<br>
I trust that your changes will undergo external review?<br>
<br>
David<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">---------------------------------------------------------------------<br>
Intel Corporation (UK) Limited<br>
Registered No. 1134945 (England)<br>
Registered Office: Pipers Way, Swindon SN3 1RJ<br>
VAT No: 860 2173 47<br>
<br>
This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<br>
<br>
</div></div></blockquote></div><br></div>