weixin_39575047
weixin_39575047
2020-12-25 17:59

Cmake build and test automation

Here is a set of patches that implement CMake-based build automation and unit testing. Here is what these scripts can (and cannot) do:

Features

Building

The scripts intended to mimic the capabilities of the original GNU Makefiles but enhance them with a little CMake awesome. The scripts start off as:

CMake
#
# Behavioural options for the solution
#
  option(TRISYCL_OPENMP "triSYCL multi-threading with OpenMP" ON)
  option(TRISYCL_NO_ASYNC "triSYCL use synchronous kernel execution" OFF)
  option(BUILD_OPENCL "triSYCL build OpenCL tests" ON)
  option(BUILD_XILINX "triSYCL build Xilinx-specific tests" OFF)
  option(TRISYCL_DEBUG "triSCYL use debug mode" OFF)
  option(TRISYCL_DEBUG_STRUCTORS "triSYCL trace of object lifetimes" OFF)

  set(CL_SYCL_LANGUAGE_VERSION 220 CACHE VERSION "Host language version to be used by trisYCL (default is: 220)")
  set(TRISYCL_CL_LANGUAGE_VERSION 220 CACHE VERSION "Device language version to be used by trisYCL (default is: 220) (not used yet)")

These variables can be set from the command-line at configuration time. The default values I hope make sense for the vast majority of development scenarios.

Testing

The scripts also hook unit testing into the familiar CTest framework. These scripts do not rely on LIT being present (one less dependency), because none of the unit tests used any features that are not present in CTest. CTest produces similarly sexy output as LIT, can test exit codes and match stdout vs. a regex.

Warning-free

As a good habit of mine, I raise the warning level on all compilers to the highest value, and went ahead and disabled warnings specifically that triggered in any of the tests. I would like to invite all devs to take on their favorite compiler they use to develop/consume triSYCL and get rid of all the warnings one by one. Some are fairly banal, but some may be quite severe.

Notes

The multiple_compilation_units tests fails on almost all compilers with the output being scrambled even though the NO_BARRIER define is set in code. What is the reason for this?

CMake
add_compile_options("/wd4459") # warning C4459: declaration of '<id>' hides global declaration
add_compile_options("/wd4456") # warning C4456: declaration of '<id>' hides previous local declaration
</id></id>

For instance in the case of MSVC is either a two-phase name lookup error or a potential source of a serious bug. These options can be found in the top-level CMakeLists.txt file for all compilers.

Tested platforms

Windows 10 + VS 15 + Boost 1.63.0

Importing the environment of a developer command prompt, (and having the Ninja build system for eg. on the path), one can do something like:

PowerShell
PS C:\Users\Matty\Build\triSYCL> Import-CmdEnvironment 'C:\Kellekek\Microsoft\Visual Studio\15RC\VC\Auxiliary\Build\vcvars64.bat'
PS C:\Users\Matty\Build\triSYCL> cmake.exe -G"Ninja" -DBoost_COMPILER="-vc140" C:\Users\Matty\Source\Repos\triSYCL\

This creates Ninja makefiles that can be invoked as simply as:

PowerShell
PS C:\Users\Matty\Build\triSYCL> cmake --build .

which essentially invokes the underlying build systems 'all' target. After build is complete, one can run tests simply by typing:

PowerShell
PS C:\Users\Matty\Build\triSYCL> ctest

which essentially invokes the underlying build systems 'test' target.

Notes

Because the FindBoost.cmake scripts wrongly expected the toolset of VS 15 to be v150 (instead of v141) one manually has to set the toolset version by configuring using -DBoost_COMPILER="-vc140". One might ask: why 140 and not 141? Because even the coming Boost 1.64 does not compile with the new toolset, due to it having gone ahead and riding the STL of deprecated STL functions such as std::unary_function which Boost does not handle yet.

There was a hard error in one of the samples from a narrowing conversion.

Ubuntu 16.04 (WSL) + GCC 6.2 + Boost 1.58.0

Configure using:

Bash
mnagy-Z50-75:~/build/triSYCL/gcc-6.2$ cmake -DCMAKE_C_COMPILER=gcc-6 -DCMAKE_CXX_COMPILER=g++-6 /mnt/c/Users/Matty/Source/Repos/triSYCL/

Building using:

Bash
mnagy-Z50-75:~/build/triSYCL/gcc-6.2$ cmake --build . -- -j5

Testing:

Bash
mnagy-Z50-75:~/build/triSYCL/gcc-6.2$ ctest

Notes

I removed the spurious typename keyword from the jacobi-helpers.hpp header, because it resulted in warnings I could not disable.

Ubuntu 16.04 (WSL) + Clang 4.0 + Boost 1.58.0

Configure using:

Bash
mnagy-Z50-75:~/build/triSYCL/clang-4.0$ cmake -DCMAKE_C_COMPILER=clang-4.0 -DCMAKE_CXX_COMPILER=clang++-4.0 -DTRISYCL_OPENMP=OFF /mnt/c/Users/M
atty/Source/Repos/triSYCL/

Building using:

Bash
mnagy-Z50-75:~/build/triSYCL/clang-4.0$ cmake --build . -- -j5

Testing:

Bash
mnagy-Z50-75:~/build/triSYCL/clang-4.0$ ctest

Notes

I could not get Clang actually work with OpenMP. It throws a runtime (?!?!) exception for using unimplemented feature. Otherwise omitting OpenMP results in some dead-locking tests.

该提问来源于开源项目:triSYCL/triSYCL

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

4条回答

  • weixin_39575047 weixin_39575047 3月前

    The Xilinx-specific test is disabled for now, because it is not out-of-source friendly and requires changes to the source code, but because I do not have such an SDK, I cannot test it. For an OpenCL application to always find the kernel code, one could obtain the neccessary info from the build system, such as can be seen in a repo of mine that uses CMakes configure_file option to create a header with the path to the kernel.

    One has many other options, such as always copying the kernel code over to the binary dir with the file(COPY ... DESTINATION ...) command. Byproducts created by external tools from the SDK can use custom_target command and specify BYPRODUCTS of invoking the target which the original target can depend on simply by adding them to the input files.

    点赞 评论 复制链接分享
  • weixin_39575047 weixin_39575047 3月前

    As a side note, I did not want the scope of the PR to include this issue, but right now all tests include and link to OpenCL unconditionally (see lines 39 and 45 of tests/CMakeLists.txt), because some include paths somehow include CL/cl.h, even if the test has no OpenCL in it. I think it would be better if one could test triSYCL without a functioning OpenCL installation.

    点赞 评论 复制链接分享
  • weixin_39843698 weixin_39843698 3月前

    Thanks a lot for this great improvement!

    点赞 评论 复制链接分享
  • weixin_39843698 weixin_39843698 3月前

    I've added most of the description of this PR in https://github.com/triSYCL/triSYCL/commit/103f73d796c5af1e0cf625fa44b1f766325b2d04

    点赞 评论 复制链接分享