Implement CMake-based build of TBB for easy embedding into open-source projects

[anton-malakhov]

See discussion at #2 (comment)

[wjakob]

I maintain a CMake build system overlay here: https://github.com/wjakob/tbb
It works on all major platforms and is tested by continuous integration bots on Windows (AppVeyor) and Linux + MacOS (Travis CI).

[wjakob]

I would be happy to sign this over under any license so that Intel can incorporate the changes into their regular TBB releases (in fact, I'd be more than happy because I wouldn't have keep updating the build system for each and every new version. :))

[tbbdev]

Hello, wjakob.
Thank you for your effort in making TBB more friendly for CMake build system overlay.
TBB engineering team is working now on enabling easy TBB integration into CMake based projects. When we include this improvement into release we will inform you about it.

[tbbdev]

Hello, All.
We are glad to announce that we added initial support for Intel TBB integration into CMake-aware
projects. Please, evaluate it: https://github.com/01org/tbb/tree/tbb_2017/cmake

[Anteru]

I'm not sure that's what people asked for. Your "CMake integration" ignores the host CMake project and just shells out to make to build TBB, and is thus more or less worthless (you might as well just provide a TBB-config.cmake file to simplify a Find call), as it ignores the compile options and other CMake project settings. It also ignores the CMake build settings; I can't build a "RelWithDebug" using this integration, I can just build the stuff which is already pre-packaged in the binary release, but it may or may not be ABI compatible with what I'm currently compiling.

A find module for CMake would have been more useful than this wrapper. If you're going the build route, why not use ExternalProject which is CMake's method of calling another build tool? (See: https://cmake.org/cmake/help/v3.9/module/ExternalProject.html)

While I'm really happy there's progress on this front, @wjakob CMake integration remains much more useful for CMake based projects.

[wjakob]

Agreed -- I plan to continue maintaining my repository.

@tbbdev: if you'd like to integrate my CMakeLists.txt (or a variant thereof) into the official distribution at some point, you have my permission (and I am happy to sign an CLA). It would make my life easier ;)

[henryiii]

I really appreciate the effort to add CMake integration via configure scripts. However, the current version seems quite buggy; and because it is not integrated into the default build, it is not usable since find_package will be unable to find an install that forgot to run the extra cmake script to generate the config (most installs, like Homebrew, are missing this step). And, when this extra, non-standard step is added to Homebrew, the Config script fails to find the correct paths anyway.

Recommendations: do one or both of the following:

• Add the generation of PREFIX/lib/cmake/TBB/TBBConfig.cmake to the makefile script. There's no need to actually use CMake to make a *Config.cmake script, you just need regex or similar to add paths to the file.
• Add a normal-looking CMakeLists.txt to the main repo that also can build TBB. This would then use standard CMake language to produce the Config files, and users/package managers would know how to make them. This would support the "build as part of your package" options much more naturally than the current method; a user would just do add_subdirectory(tbb).

See here for an example of adding TBBConfig to the brew formula, and if you try it on macOS, you'll find it is broken, component tbb cannot be found.

[hepcatjk]

@tbbdev - I just found this thread, and I highly agree with integrating @wjakob -> https://github.com/wjakob/tbb
such that you can call -> add_subdirectory(tbb) or use the build system. - The current tbb_build works fine on linux but is nothing but headaches on supporting projects on windows.

One of the biggest uses is to use this repo as a submodule that you can build and include in your project or deployment and the tbb_build system is nothing but a mess to make sure it plays nicely out of the box for users using Visual Studio.

I highly support rolling in @wjakob 's changes into this repo !!!!

[anton-malakhov]

Just a side comment on how easy it is to build TBB on Windows. Please take a look at how conda-forge builds TBB package:
All you need is the right gmake package. E.g. you can take m2w64-make from conda-forge channel and execute mingw32-make in order to build TBB. conda-build tool provides desired level of environment isolation so that other mingw tools like sh are not on the way.

[thewtex]

Just a side comment on how easy it is to build TBB on Windows.

This is not relevant for CMake-configured C++ projects that want to use TBB as a dependency. The majority of C++ project build systems use CMake.

While adoption of CMake for TBB itself from @wjakob would be great, the intermediate step of always generating TBBConfig.cmake from the Makefile would be a good incremental step forward, as suggested by @henryiii . Also, it seems that the generation of TBBConfig.cmake with cmake/tbb_config_generator.cmake does not appear to support binaries generated from a local source build.

[teonnik]

Is there someone still working on this issue? Many people have already chimed in and outlined the main issues with the current approach.... what CMake users really need is along the lines of https://github.com/tschw/tbb/blob/target-exports/CMakeLists.txt , which is a fork of https://github.com/wjakob/tbb (already mentioned above). The fork exports the necessary configuration files (i.e. generates appropriate *Config.cmake files) so that users only do

find_package(tbb)
target_link_libraries(my_project PRIVATE tbb::tbb_static)

and potentially use the flag -DCMAKE_PREFIX_PATH="<path_to_root_tbb>" if custom directory is used.

I don't know what the plans for the future of this project is, but having a quality CMake support should be at the top of the priority list.... it's been already 2 years since the issue was raised....

[reinago]

In our project we are also heavily relying on the ExternalProject_Add mechanism, which makes integration of other CMake-based code extremely smooth. Replacing OpenMP with TBB would be very helpful for us, especially given the OpenMP limitations in Visual Studio, but we do not want to fragment our build process again, after finally having something consistently CMake-based. So +1 from us...

[ocommowi]

Hi all,

+1 for us too. Having the TBBConfig.cmake generated when building is very good. But I agree with previous comments that having TBB use CMake to build from source would be great. That would allow inclusion in ExternalProject_Add very much easier, especially for use with the ITK library. Is there any plan for this soon?

[teonnik]

If direct CMake support is not an option at the moment, can we get a pkg-config file as discussed in #5 ? We can then use the project from most modern build systems like CMake, Meson and build2. For CMake we can use the FindPkgConfig module to include tbb in an idiomatic (i.e. target-based) manner.

[jdumas]

@tbbdev Any chance of getting a proper cmake support any time soon?

[bowie7070]

I too would like to see improvements to the CMake scripts. Courtesy of @wjakob I have the following configuration using FetchContent:

include(FetchContent)
FetchContent_Declare(
    tbb
    GIT_REPOSITORY https://github.com/wjakob/tbb.git
)

FetchContent_MakeAvailable(tbb)

Would love to replace that git repo with the official Intel one.

[AlexVeprev]

TBB 2019 U5 has a new CMake module for config generation: TBBInstallConfig.cmake (developed in scope of PRs #119, #126, #127). It is not included into the TBB Makefile as a separate target yet, but can be used as a CMake module or from command line via wrapper script.
I hope it will a bit simplify use of TBB from CMake in some cases. Of course it doesn't implement build from source using CMake. But by the way I'll appreciate if someone can explain a reason to build TBB from source in client project. Why official or other TBB distributions with pre-built binaries are not suitable?

[jdumas]

Well, @Anteru explains the issue in his answer above:

I'm not sure that's what people asked for. Your "CMake integration" ignores the host CMake project and just shells out to make to build TBB, and is thus more or less worthless (you might as well just provide a TBB-config.cmake file to simplify a Find call), as it ignores the compile options and other CMake project settings. It also ignores the CMake build settings; I can't build a "RelWithDebug" using this integration, I can just build the stuff which is already pre-packaged in the binary release, but it may or may not be ABI compatible with what I'm currently compiling.

So reasons for building sources are mostly:

• Release with debug info.
• ABI compatibility for exotic configurations.

[bowie7070]

TBB 2019 U5 has a new CMake module for config generation: TBBInstallConfig.cmake (developed in scope of PRs #119, #126, #127). It is not included into the TBB Makefile as a separate target yet, but can be used as a CMake module or from command line via wrapper script.

Thanks for the suggestion. I am a bit new to cmake and I was not able to understand (from reading the documentation) how to use what was provided. On the other hand the FetchContent based approach follows easily from the documentation/examples and worked straight away.

I hope it will a bit simplify use of TBB from CMake in some cases. Of course it doesn't implement build from source using CMake. But by the way I'll appreciate if someone can explain a reason to build TBB from source in client project. Why official or other TBB distributions with pre-built binaries are not suitable?

I went for building from source because it was not clear that the released binaries would be compatible with the version of clang that I am using and the standard library that I am linking against. I also want the ability to have different versions of our software utilising different versions of TBB so I don't want to use system install directories.

[akukanov]

Release with debug info.

Note that the pre-built TBB release binaries do have debug information.

[jdumas]

I'm sorry but I still think this issue is relevant to this day. I just tried TBBuild.cmake instead of @wjakob's fork on my Windwos machine, and it complains that I don't have gmake? I'm sorry but what year is this? When can we get a cmake-based script into the upstream repo that do not require MinGW or whatever I need to install to get gmake?

Also, does TBBuild supports compiling with static runtime (/MT), e.g. using the MSVC_RUNTIME_LIBRARY option in CMake.

PS: The CMake script in @wjakob's fork is not without issue either, as indicated by the 4 open issues on the project page (e.g. it fiddles with the CMAKE_CXX_FLAGS of the host which shouldn't be needed in CMake > 3.0). It would be great if the effort could be merged somehow.

[qis]

The biggest issue with @wjakob's script is that it does not properly export targets or generate a config. Building with clang for llvm-pstl is not possible unless you go for a tagged and shared library - which is often unacceptable.

[AlexVeprev]

Hi all, I'm glad to announce that TBB migrated to CMake in oneAPI 2021.1-beta08 release. Source code was published to onetbb_2021 branch. Some instructions are provided in cmake/README.md.

Feel free to provide your feedback and contributions.

[tbbdev]

CMake support was implemented as described above. Closing the request. Please submit new issues/PRs for problems and proposals.
Known issues: #271