[Openmp-dev] [PATCH] [Revisedx2] Initial cmake support

[Jack Howarth]

James,
     Sorry about that, I assumed that you had signed off on those commits
off-list. Concerning the CMakeLists.txt files from
https://github.com/pathscale/openmprtl/tree/master/itt/libomp_oss, 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 build.pl under the cmake system.
              Jack
ps The major changes in my implementation of the cmake files compared to
those at openmprtl are...

1) Addition of the missing…

if(APPLE)
  set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
-current_version 5.0")
  set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
-compatibility_version 5.0")
endif()

2) Addition of the missing…

if (NOT APPLE)
  set(FEATURE_FLAGS "${FEATURE_FLAGS} -D KMP_TDATA_GTID")
endif()

to make the cmake build on linux match the build.pl one.

3) Addition of thirdparty/ittnotify/ittnotify_static.c to the SOURCES file
list and

set(FEATURE_FLAGS "${FEATURE_FLAGS} -D INTEL_ITTNOTIFY_PREFIX=__kmp_itt_")
set(FEATURE_FLAGS "${FEATURE_FLAGS} -D USE_ITT_NOTIFY=1")
set(FEATURE_FLAGS "${FEATURE_FLAGS} -D INTEL_ITTNOTIFY_PREFIX=__kmp_itt_")

to make the cmake build on linux and darwin match the one using build.pl.
Windows is untested of course.

4) Addition of  kmp_cancel.cpp and kmp_itt.c to SOURCES file list to match
the build from build.pl on darwin and linux.

5) Removal of kmp_ftn_stdcalls.c from the SOURCES file list as it is not
used in the build from build.pl on either darwin or linux.

6) Addition of the missing "-D KMP_ASM_INTRINS" to the add_custom_command
for generating z_Linux_asm.o so that behavior of build.pl is emulated in
cmake. I did this because I noticed that  z_Linux_asm.s contained a
preprocessor testing this variable.

7) Implemented the use of...

set(OMP_SHLIBEXT "${CMAKE_SHARED_LIBRARY_SUFFIX}")

to handle the shared library suffix in a generic manner.

8) Added the missing…

set(FEATURE_FLAGS "${FEATURE_FLAGS} -D KMP_USE_ADAPTIVE_LOCKS=1")
set(FEATURE_FLAGS "${FEATURE_FLAGS} -D KMP_DEBUG_ADAPTIVE_LOCKS=0")

for darwin and linux to match the behavior of build.pl.

9) Used…

set(COMMON_FLAGS "${COMMON_FLAGS} -Wno-unused-value")
set(COMMON_FLAGS "${COMMON_FLAGS} -Wno-switch")
set(COMMON_FLAGS "${COMMON_FLAGS} -Wno-deprecated-register")

to match the warning flags emitted for "make compiler=clang" by build.pl on
darwin and linux.


On Mon, Jun 2, 2014 at 6:19 AM, Cownie, James H <james.h.cownie at intel.com>
wrote:

> OK, sorry, my tone may have been wrong here.
>
> I am absolutely glad to have people contributing, and certainly don't want
> to put people off.
> (ISTR that I bought Alp at least one beer when we met in London :-)).
>
>
> -- Jim
>
> James Cownie <james.h.cownie at intel.com>
> SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
> Tel: +44 117 9071438
>
>
> -----Original Message-----
> From: David Chisnall [mailto:dc552 at cam.ac.uk]
> Sent: Monday, June 02, 2014 11:14 AM
> To: Cownie, James H
> Cc: Alp Toker; Jack Howarth; openmp-dev at dcs-maillist2.engr.illinois.edu;
> "C. Bergström"
> Subject: Re: [Openmp-dev] [PATCH] [Revisedx2] Initial cmake support
>
> Hi Jim,
>
> I think there are a few things seriously wrong here.
>
> On 2 Jun 2014, at 10:50, Cownie, James H <james.h.cownie at intel.com> wrote:
>
> > * You are moving too fast; all of this has been done since noon on
> > Friday here in the UK,  and I was out on Friday afternoon and do not
> > work at weekends. I have therefore had no chance to  look at it before
> > it was checked in. (And I'm supposed to be a key reviewer and
> > architect here...)
> >
> > * A change like this (which provides a whole new build system) requires
> more than one review.
>
> 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.
>
> > * Since everyone complained so much, we have been working on a CMAKE
> > based build system here at Intel  that we hope to push this week,
> > which *does* support Windows, icc, gcc, clang etc
>
> 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.
>
> 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.
>
> 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.
>
> > So, at the point when I commit that, I'm going to remove these changes.
>
> I trust that your changes will undergo external review?
>
> David
>
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20140602/4273db80/attachment.html>