<div dir="ltr">   Using the overall file locations and structure from the openmprtl site, this shouldn't be that hard to set the cmake build machinery up. For example, the Cmakefiles.txt in openmp-3.5.0/runtime would just be something like…<div>
<br></div><div><div>cmake_minimum_required(VERSION 2.8.1)</div><div><br></div><div>project(libiomp)</div><div><br></div><div>enable_language(C ASM)</div><div><br></div><div>set(VERSION 5)</div><div>set(OMP_VERSION_NUM "40")</div>
<div><br></div><div># set debug as default build</div><div>if("${BUILD_TYPE}" STREQUAL "")</div><div>        set(BUILD_TYPE "Debug")</div><div>endif()</div><div><br></div><div># set 64bit as default architecture</div>
<div>if("${ARCH}" STREQUAL "")</div><div>        set(ARCH "32e")</div><div>endif()</div><div>set(ARCH_STR "Intel(R) 64")</div><div><br></div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D USE_ITT_BUILD")</div>
<div>set(COMMON_FLAGS "${COMMON_FLAGS} -D NDEBUG")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_ARCH_STR=\"\\\"${ARCH_STR}\\\"\"")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D _GNU_SOURCE")</div>
<div>set(COMMON_FLAGS "${COMMON_FLAGS} -D _REENTRANT")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_USE_ASSERT")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D BUILD_I8")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D BUILD_TV")</div>
<div>if(APPLE)</div><div>        set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_LIBRARY_FILE=\\\"libiomp5.dylib\\\"")</div><div>else()</div><div>        set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_LIBRARY_FILE=\\\"libiomp5.so\\\"")</div>
<div>endif()</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_VERSION_MAJOR=${VERSION}")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D CACHE_LINE=64")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_ADJUST_BLOCKTIME=1")</div>
<div>set(COMMON_FLAGS "${COMMON_FLAGS} -D BUILD_PARALLEL_ORDERED")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_ASM_INTRINS")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D USE_LOAD_BALANCE")</div>
<div>set(COMMON_FLAGS "${COMMON_FLAGS} -D USE_CBLKDATA")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D GUIDEDLL_EXPORTS")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_GOMP_COMPAT")</div>
<div>set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_USE_ADAPTIVE_LOCKS=1")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D KMP_DEBUG_ADAPTIVE_LOCKS=0")</div><div><br></div><div>if("${OMP_VERSION_NUM}" STREQUAL "40")</div>
<div>        set(COMMON_FLAGS "${COMMON_FLAGS} -D OMP_50_ENABLED=0")</div><div>        set(COMMON_FLAGS "${COMMON_FLAGS} -D OMP_41_ENABLED=0")</div><div>        set(COMMON_FLAGS "${COMMON_FLAGS} -D OMP_40_ENABLED=1")</div>
<div>        set(COMMON_FLAGS "${COMMON_FLAGS} -D OMP_30_ENABLED=1")</div><div>endif()</div><div><br></div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D USE_ITT_NOTIFY=1")</div><div>set(COMMON_FLAGS "${COMMON_FLAGS} -D INTEL_ITTNOTIFY_PREFIX=__kmp_itt_")</div>
<div><br></div><div>set(C_CXX_COMMON_FLAGS "${C_CXX_COMMON_FLAGS} -fPIC")</div><div><br></div><div>if(${BUILD_TYPE} STREQUAL "Debug")</div><div>        set(COMMON_FLAGS "${COMMON_FLAGS} -g")</div>
<div>endif()</div><div><br></div><div># Silence some warnings</div><div>set(C_CXX_COMMON_FLAGS "${C_CXX_COMMON_FLAGS} -Wno-unused-value")</div><div>set(C_CXX_COMMON_FLAGS "${C_CXX_COMMON_FLAGS} -Wno-switch")</div>
<div>set(C_CXX_COMMON_FLAGS "${C_CXX_COMMON_FLAGS} -Wno-switch")</div><div><br></div><div># Disable exception handling.</div><div>set(C_CXX_COMMON_FLAGS "${C_CXX_COMMON_FLAGS} -fno-exceptions")</div><div>
<br></div><div># Disable use of EBP as general purpose register.</div><div>if(NOT ${ARCH} STREQUAL "64")</div><div>        set(C_CXX_COMMON_FLAGS "${C_CXX_COMMON_FLAGS} -fno-omit-frame-pointer")</div><div>
endif()</div><div><br></div><div>set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMMON_FLAGS} ${C_CXX_COMMON_FLAGS}")</div><div>set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMMON_FLAGS} ${C_CXX_COMMON_FLAGS}")</div>
<div><br></div><div>add_subdirectory(src)</div></div><div><br></div><div>   IMHO, I don't think there is much intellectual property here as it is a fairly standard cmake syntax which is adjusted to mimic the flags emitted by the current <a href="http://build.pl">build.pl</a> scripts (which is how I made my adjustments anyway).</div>
<div>       Jack</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 30, 2014 at 12:37 PM, Jack Howarth <span dir="ltr"><<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Alp,<div>    Are you thinking of these?</div><div><br></div><div><a href="https://github.com/pathscale/openmprtl/blob/master/itt/libomp_oss/CMakeLists.txt" target="_blank">https://github.com/pathscale/openmprtl/blob/master/itt/libomp_oss/CMakeLists.txt</a><span class="HOEnZb"><font color="#888888"><br>

</font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>           Jack</div></font></span><div>ps Worse case we can at least look at those as a template on how to construct ours.</div></div><div class="HOEnZb">
<div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 30, 2014 at 11:00 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
On 30/05/2014 17:51, Jack Howarth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Should it be an out of source build like libcxx?<br>
</blockquote>
<br></div>
Yep, exactly.<br>
<br>
Will try to dig up the CMake files, they're pretty neat. Some Intel/icc-specific functionality is missing IIRC but otherwise fine.<br>
<br>
Alp.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<br>
On Fri, May 30, 2014 at 8:56 AM, John Leidel (jleidel) <<a href="mailto:jleidel@micron.com" target="_blank">jleidel@micron.com</a> <mailto:<a href="mailto:jleidel@micron.com" target="_blank">jleidel@micron.com</a>>> wrote:<br>


<br>
    Why not structure this as an LLVM "project" as defined in<br>
    <a href="http://llvm.org/docs/Projects.html" target="_blank">http://llvm.org/docs/Projects.<u></u>html</a>?<br>
<br>
<br>
    John D. Leidel<br>
<br>
    On May 30, 2014, at 7:30 AM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a><br></div><div>
    <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
    ><br>
    > On 30/05/2014 15:18, Jack Howarth wrote:<br>
    >>    Has anyone started on integrating the openmp build into the<br>
    llvm build yet? If not, I would suggest we start by borrowing the<br>
    build machinery files from polly as the starting point. Like<br>
    polly, openmp provides a support library for the compiler and<br>
    should be built in the tools subdirectory..<br>
    ><br>
    > Polly is completely different to the OpenMP runtime. Polly uses<br>
    LLVM libraries, and can be seen as part of the compilation host<br>
    toolchain, while this is an independent runtime library that runs<br>
    on the target. So the build systems are tangential.<br>
    ><br>
    ><br>
    >> Also, the polly cmake  and autogen directories are fairly<br>
    spartan so they should be easy to refashion for openmp.<br>
    ><br>
    > There's a simple CMake setup on one of the GitHub branches of<br>
    this project, C. Bergström may know better if they can be<br>
    contributed. Either way that's closer to what's needed here.<br>
    ><br>
    > Alp.<br>
    ><br>
    ><br>
    >>           Jack<br>
    >><br>
    >><br>
    >> ______________________________<u></u>_________________<br>
    >> Openmp-dev mailing list<br>
    >> <a href="mailto:Openmp-dev@dcs-maillist2.engr.illinois.edu" target="_blank">Openmp-dev@dcs-maillist2.engr.<u></u>illinois.edu</a><br></div>
    <mailto:<a href="mailto:Openmp-dev@dcs-maillist2.engr.illinois.edu" target="_blank">Openmp-dev@dcs-<u></u>maillist2.engr.illinois.edu</a>><div><br>
    >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/openmp-dev</a><br>
    ><br>
    > --<br>
    > <a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
    > the browser experts<br>
    ><br>
    > ______________________________<u></u>_________________<br>
    > Openmp-dev mailing list<br>
    > <a href="mailto:Openmp-dev@dcs-maillist2.engr.illinois.edu" target="_blank">Openmp-dev@dcs-maillist2.engr.<u></u>illinois.edu</a><br></div>
    <mailto:<a href="mailto:Openmp-dev@dcs-maillist2.engr.illinois.edu" target="_blank">Openmp-dev@dcs-<u></u>maillist2.engr.illinois.edu</a>><br>
    > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/openmp-dev</a><br>
<br>
<br>
</blockquote><div><div>
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>