• d81529d by @hernando started support for multiple test suites. This caused higher-level cppcheck targets not to run anymore, and in reality only worked for one instance of cpp ctests.
• Each test is now run as a separate ctest (side benefit: parallel tests as per '-j' build command line!). This also simplifies perf/unit test separation
• Directly add run_cppcheck targets to tests target instead of using add_test.
• Doxygen depends only on project tests for coverage, not on all tests
• Remove cppcheck and cpplint tests, covered by run_ targets now.
• Jenkins will need to change to use 'make tests' instead of ctest directly. ctest command line parameters needed for this change are included here

GitExternal is using a potentially non-existing directory to clone it when COMMON_SOURCE_DIR is set, however the git command doesn't need any specific working directory to do the job.

Takes the basic idea from BRayns, luckily common_package is a macro to allow the retur() out of the top-level CMakeLists. Sample configure run provided below. Also removed the superfluous/harmful extra find_package in SubProject.cmake @biddisco complained about.

-- Configured Hello [ff94cfa] with Boost
-- Configured Servus [4e4ea43] with DNSSD Boost Threads
-- Configured Deflect [83aaa6b] with Boost GLUT LibJpegTurbo OpenGL Qt5Concurrent Qt5Core Qt5Network Qt5Qml Qt5Quick Qt5Widgets Servus
-- Configured ZeroBuf [23ac6b4] with Boost Servus
-- Configured Lunchbox [33a354c] with Boost leveldb Servus WITHOUT hwloc MPI OpenMP skv
-- Not configured osgTransparency: Required OpenSceneGraph not found
-- Configured Pression [e813e22] with LibJpegTurbo Lunchbox WITHOUT OpenMP
-- Configured vmmlib [66a1b6d] with Boost
-- Configured Brion [d76760e] with BBPTestData Boost HDF5 Lunchbox vmmlib WITHOUT OpenMP
-- Configured Collage [fa984ee] with Boost Lunchbox Pression WITHOUT OFED UDT
-- Configured dash [6e05142] with Boost Lunchbox
-- Configured TUIO [b002886] with GLUT OpenGL SDL
-- Not configured DisplayCluster: Required MPI not found
-- Configured GLStats [3c76246] with Lunchbox OpenGL
-- Configured hwsd [bb9fea4] with Boost Lunchbox OpenGL Qt5Core Qt5Network Servus X11
-- Configured zeq [6229239] with Boost FlatBuffers libzmq Servus Threads ZeroBuf
-- Configured BBPSDK [b248d40] with BBPTestData Boost Brion Java JNI Lunchbox PythonInterp PythonLibs vmmlib WITHOUT BBPDocumentation OpenMP SWIG
-- Configured Equalizer [7bfcd4a] with Boost Collage Deflect GLStats hwsd Lunchbox MAGELLAN OpenGL Pression Qt5Core Qt5Gui Qt5Widgets vmmlib VRPN GLEW_MX WITHOUT hwloc OpenCV OpenSceneGraph X11 hwloc
-- GLX window system not supported: Skipping example eqCPU
-- Linking boost testing libs dynamically...
-- Boost version: 1.59.0
-- Found the following Boost libraries:
--   unit_test_framework
--   system
--   regex
--   date_time
--   thread
--   filesystem
--   program_options
--   chrono
--   atomic
-- Configured RESTBridge [a126090] with Boost cppnetlib FlatBuffers zeq
-- Configured Monsteer [96c8f40] with BBPTestData Boost Brion FlatBuffers Lunchbox PythonInterp PythonLibs vmmlib zeq WITHOUT MPI music
-- Configured NeuMesh [b6d1f48] with BBPSDK BBPTestData Boost Brion GTK2 GTS HDF5 Lunchbox OpenGL PythonInterp vmmlib VTK WITHOUT OpenMP
-- Not configured BRayns: Required OSPRay not found
-- Configured Livre [af4e4b8] with BBPTestData Boost Collage dash Equalizer FlatBuffers GLEW_MX LibJpegTurbo Lunchbox Monsteer OpenGL PNG Qt5Core Qt5OpenGL Qt5Widgets RESTBridge Threads zeq WITHOUT OpenMP Tuvok VTune
-- Not configured RTNeuron: Required OpenSceneGraph not found
-- Configured Cubist [0875a40] with Boost GLEW_MX Livre OpenGL VTK
-- Performing Test C_HAS_WARNING-Wformat=2
-- Performing Test C_HAS_WARNING-Wformat=2 - Success
-- Performing Test CXX_HAS_WARNING-Wformat=2
-- Performing Test CXX_HAS_WARNING-Wformat=2 - Success
-- Configured Fivox [788753c] with BBPSDK BBPTestData Boost Monsteer ITK Livre vmmlib libzmq
-- Configured livreDatasources [9484809] with Boost HDF5 Livre
-- Configured bbp [e41c4bc]
-- Configuring done

The file CommonCompiler.cmake force the usage of the flag -WError.

His usage is completely understandable and justified for build in "Debug" mode. It is however a bad practice to enable it by default for release build due to its tendency to break the build each time a new compiler implement new warning reporting.

Could you please, enable this flag only when the build is configured in "Debug" mode ?

Thank you in advance, Adev

• before, ${PROJECT_SOURCE_DIR}/${PROJECT_INCLUDE_NAME} was being used as one of the 'gathering' directories, made this more general, so source trees with different layouts will work
• also fixed a typo

Some projects put their ${project}Config.cmake files in locations other than the root. The recent changes to SubProjects added an automatic find and do not look in those locations.

Added an input variable to choose the target libraries to export instead of all the generated ones. Fixed extraction of library names from target properties.

The intention of this change is to restrict the libraries exported by FOOConfig.cmake to those that provide the C++ API being exported (for example, python binding libraries can be filtered out).

By default, the flag -std=c++11 is set. But when using COMMON_USE_CXX03, neither -std=c++98 nor -std=c++03 is used. It would be good to set this flag for consistency. It will also make it easier to manage standard conformance consistently for both C++11 and C++03 standards by using the pedantic flags.

@tribal-tec FYI - This folder was removed from includes in #284 . This breaks the compilation of BBPSDK after the update:

https://bbpcode.epfl.ch/ci/job/common.BBPSDK.gerrit/build_type=Debug,platform=cscsviz/261/testReport/projectroot.gpfs.bbpcscsch.home.bbprelman.jenkins-cscs-02.workspace.commonBBPSDKgerrit.build_type.Debug.platform.cscsviz/BBP/cppcheck_test_BBPSDK/

When running cmake, a subproject module is initialized and cloned, but this project modules are not cloned, however, causing the build to fail.

https://github.com/Eyescale/CMake/blob/935807ce40c04e507063e45a5286cf1804f5cf45/GitExternal.cmake#L114

The reason is that the call to git submodule init is not recursive, not registering the paths of the subproject module's modules, thus when the git submodule update --recursive call is executed, these non registered paths are not cloned. Executing these 3 commands manually results in the same behaviour.

The test case is Brion https://github.com/BlueBrain/Brion The scenario where this happens occurs when dealing with its sub module "libsonata". The structure is:

- Brion
    - libsonata
        - HighFive
        - fmt

If Brion is the subproject, when building, libsonata will be cloned, but HighFive and fmt (which are git submodules) will not be cloned.

adding --init to the line pointed above solves the problem, although it clones again CMake/common.

This can be fixed manually by running git submodule udpate --init in the problematic subprojects, however this cannot be applied to the CI jobs.

Hi, is there any way to disable all the extra targets that cmakecommon generate? Im thinking about project-tarball, project graph, cpplint, clangchecks and all that.

Thanks

I reopen this issues because I think that your answer doesn't solve it and I think it's not correct. Of course I may be wrong, but in any case, proves that the original answer didn't solve my doubts. For anyone looking at this, the original question and answer are below.

I have just done a really simple plain CMake project

cmake_minimum_required(VERSION 3.5)
PROJECT(StupidCMake)

find_package(SUtils REQUIRED)

If SUtils is not found, CMake will complains saying that you should provide a FindSUtils.cmake or point SUtils_DIR to a dir containing SUtilsConfig.cmake.

If, without deleting the cache, you try to reconfigure providing that dir, it will find the library. You can try it with any of your libraries, I have check it with mine. This is the behavior I would expect from CMakeCommon also. As this is not the case, I would say that this is a CMakeCommon feature/bug. How can I make it work in the original way?

[Original question] Imagine that you have a library which doesn't provide a FindFoo.cmake and therefore you use FooConfig.cmake. You should provide Foo_DIR for CMake to find it. If you forget to add it, CMake will complain, but if you add it after the first configuration, it will stay says that it can't be found.

The only way I've found to solve this is to remove the CMakeCache (or remove just the entries related with Foo) and reconfigure, but its really annoying to have to do this.

Is this a bug or am I using it wrong?

[Original answer] Regretfully, this is a CMake "feature". The variables that decide that a library was not found are cached, so next time CMake runs it doesn't need to resolve them again. Forcing CMake to ignore these variables will basically render the cache useless. Another example is changing the compiler used for building. Once a compiler is detected, you cannot change it without removing the cache.

Hi, ive been using CMakeCommon for a while now, but ive not been able to compile any library which uses CUDA.

If I try to compile using cuda_add_library, CMakeCommon complains that the target is not exported, but if I try to compile using common_library, g++ is used and not nvcc.

I believe that I should modify CMAKE_C_COMPILER and CMAKE_CXX_COMPILER to use nvcc and a compatible gcc compiler. I thought that was that CommonCUDA did, but it seems there is a bug in the string(REGEX REPLACE) command.

What should I do?

Thanks!