Enable MultiConfig builds

[alliepiper]

Fixes #1159.

Also fixes or works around these issues:

• WAR SM arches 5.3, 6.2, 7.2 fail to build with RDC enabled. #1167: Disable arches 53, 62, 72 by default.
• Fixes OpenMP and TBB tests should run serially #1168: Set RUN_SERIAL on OpenMP and TBB tests.
• WAR Can't cache nvcc objects when compiling with "-Werror all-warnings" ccache/ccache#598:
  nvcc flags s/-Werror all-warnings/-Xcudafe --promote_warnings/g
• WAR Cannot build tbb.cuda configurations with warning promotion enabled #1174: remove warning promotion from tbb.cuda targets.
• WAR Support adding Thrust to CMake projects with add_subdirectory #976: Add options to enable/disable tests, examples, header_tests:
  • THRUST_ENABLE_TESTING
  • THRUST_ENABLE_EXAMPLES
  • THRUST_ENABLE_HEADER_TESTING
  • THRUST_ENABLE_EXAMPLE_FILECHECK

Summary:

• Bump CMake requirement to 3.15
  • Needed for CUDA_COMPILER_ID generator expression.
  • Removed workarounds for older CMake versions.
• Removed warning flag specific to for C++98.
• Dialects are now configured through target properties. Add new
  THRUST_CPP_DIALECT option for single config mode, and remove logic
  that modified CMAKE_CXX_STANDARD and CMAKE_CUDA_STANDARD.
• Move testing related CMake code to testing/CMakeLists.txt
• Move example related CMake code to examples/CMakeLists.txt
• Move header testing related CMake code to
  cmake/ThrustHeaderTesting.cmake
• Move CUDA configuration logic to cmake/ThrustCUDAConfig.cmake.
• Explicitly include(cmake/*.cmake) files rather than searching
  CMAKE_MODULE_PATH -- we only want to use the ones in the repo.
• Added ThrustMultiConfig.cmake
  • Handle MultiConfig (and single config) logic.
• Added ThrustBuildTargetList.cmake
  • Builds the THRUST_TARGETS list, which contains one interface target
    for each enabled host/device/dialect configuration.
• Added ThrustBuildCompilerTargets.cmake
  • Move warning flag, etc setup into it, bind compile interfaces to
    targets instead of global variables.
• Removed common_variables.cmake and simplified FileCheck hooks.
  • Set THRUST_ENABLE_EXAMPLE_FILECHECK to turn on FileCheck validation
  • Automatically detect and set THRUST_FILECHECK_EXECUTABLE if installed
    and filechecking is enabled.
• Removed THRUST_TREAT_FILE_AS_CXX
  • This worked by setting a cmake SOURCE_FILE property, which no longer
    works since multiconfig may build the same source file with both CXX
    and CUDA.
  • Instead, the .cu files are wrapped in a .cpp file that does
    nothing but include the .cu file. The .cpp files are then added
    to the CXX targets as sources.
  • See cmake/ThrustUtilities.cmake for implementation.
• Fix bug in thrust-config.cmake where an internal var was not cached as
  expected.

[brycelelbach]

Can we rename run_example.cmake and run_test.cmake to be consistent with the other CMake files in cmake/?

[brycelelbach]

We should probably avoid using "meta" in the context of multiconfig builds to avoid confusion with C++ metaprogramming.

[brycelelbach]

Previously the default output location for the binaries was the top level build directory; now the binaries are in testing and examples. Should we put them back in the top level build directory? Or in a bin directory? Same question for the test framework library.

[brycelelbach]

Put this in one of the top-level .md documents, like README?

[alliepiper]

I'll add a section on MultiConfig to CONTRIBUTING.md at some point, either in this patch or #1163 (since CONTRIBUTING doesn't exist yet).

[brycelelbach]

@griwes any concerns about this?

[alliepiper]

The tl;dr behind this is that we can't set the "treat as cpp" flag as a source file property anymore, since each source file is now compiled multiple times for multiple targets, some of which may still need to treat the file as CUDA.

Instead, a .cpp file is generated that just does #include <thrust/original/file.cu>, and that cpp file is compiled instead of the .cu.

[alliepiper]

Previously the default output location for the binaries was the top level build directory; now the binaries are in testing and examples. Should we put them back in the top level build directory? Or in a bin directory? Same question for the test framework library.

This is super easy to change by setting this variable (or the equivalent target property) https://cmake.org/cmake/help/v3.15/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY.html

I like putting them in bin but can adapt to any of these suggestions (including leaving them where they are). Does anyone have a strong feeling on either of these choices? I'll set up the standard <build-dir>/bin/, lib/ etc locations unless anyone objects.