eyescale / cmake Goto Github PK

on un*x-systems, cmake --install will install to /usr by default:

i think this is really harmful, as the expected place is /usr/local, and on typical Linux distributions /usr is reserved for package-manager-installed software.

Also, there might be different permissions setup of installing to /usr rather than to /usr/local.
E.g. on macOS, a simplecmake --install (of Servus, which uses the Eyescale/CMake snippets) fails, because we cannot just install to /usr/share (even when run with sudo)

Some distro's use different location than the preset /usr/share/PROJECT/doc, so there should be easy way to override by e.g.:

$ cmake -DCOMMON_DOC_DIR=CUSTOM_DIR

I think this can be realized by using cached variables in the 'set'.

As mentioned/discussed in #491

Line 44:

set(CPPCHECK_EXECUTABLE  "notfound" CACHE PATH FORCE "")

should be replaced by

set(CPPCHECK_EXECUTABLE "notfound" CACHE PATH "" FORCE)

see http://www.cmake.org/cmake/help/cmake2.6docs.html#command:set.

Tests (Linux 64, Ubuntu 13.04, CMake 2.8.10.1) show that CPPCHECK_EXECUTABLE can be set to notfound;CACHE;PATH;FORCE instead of being reset to "" in case of an incorrect installation.

Line 168

list(REMOVE_AT _input ${_unused_func})

is reminiscent of the (questionable) find-optimizations in add_cppcheck_sources() but is strange for two reasons:

• it does not correspond to the test currently made on _fail_on_warn
• add_cppcheck() does not use remove instructions anywhere else

(It looks like a fortunately harmless typo.)

Two other remarks:

• add_cppcheck_sources() is not used anywhere
• the code of CppcheckTargets.cmake would be much shorter if CMakeParseArguments was used (see CMake/2.8.3).

I'm trying to use Servus in a project of mine.
Since it is not packaged for my distribution, i included Servus via a git submodule.
Servus in turn includes this repository (via git submodule, but I think that doesn't matter here).

Now trying to build the submoduled Servus fails happily with:

CMake Error: Could not open file for write in copy operation .../Servus/.git/hooks/pre-commit.tmp
CMake Error: : System Error: Not a directory
CMake Error at CMake/common/GitHooks.cmake:18 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMake/common/Common.cmake:152 (include)
  CMakeLists.txt:35 (include)

And yes, .../Servus/.git is not a directory, but a file (that contains a reference to the parent repository).
afaik, this is how git submodules work.

Since the GitHooks snippet already ignores the case where .git is missing altogether, it probably should do something sensible if it is not a directory as well...

This has also been reported in in Servus as HBPVIS/Servus#108

there should be an exception to avoid multiple copies

Has anybody used this target successfully recently?
I'm trying to use it for Brion but the target is empty.

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.

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?

• _fail is overwritten by dependent finds
• only last failure is listed
• dependencies found by the project through pkg_config are not found by installed package config
  • Create a macro to find a dependency consistently using find_package and pkg_config
  • Use macro in
    • PackageConfig
    • FindPackages
    • BY configuration

Convert paths to absolute before using them in FindLibraryPackage.cmake at while the current directory is the directory from which cmake was invoked.

It looks like the GitExternals script both includes (line 148) the .gitexternals file and also scans it for directory-repository-tag information. However the scanning script will throw a fatal error if there exists a non-comment line in the file (line 153). Doesn't this make the include redundant?

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!

Although Cppcheck targets are built and run as expected, the corresponding CMake tests (see CppcheckTargets.cmake) don't.

Precisely, only one class of tests appears as being processed in the console after typing "make test", namely the tests corresponding to the targets in Buildyard/src/Myproject/tests/, but they are not actually executed. For any other target (e.g. Buildyard/src/Myproject/apps/Myapp/main.cpp), the test is missing.

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

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

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.

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

I set up my .gitexternals file and added CMake/GitExternal.cmake and added the four lines to include GitExternal etc in my CMakeLists.txt.

Now I get this:

ergmac:build erg$ [master*] cmake ..
-- The C compiler identification is AppleClang 7.0.2.7000181
-- The CXX compiler identification is AppleClang 7.0.2.7000181
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- VERSION_ABI not set for noise. Using VERSION_MAJOR= as the ABI version.
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian
CMake Error at CMake/common/GitTargets.cmake:47 (math):
  math cannot parse the expression: " % 2": syntax error, unexpected exp_MOD,
  expecting exp_OPENPARENT or exp_NUMBER (2)
Call Stack (most recent call first):
  CMake/common/Common.cmake:124 (include)
  CMakeLists.txt:15 (include)


-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Found PROTOBUF: /usr/local/lib/libprotobuf.dylib
-- Found ROCKSDB: /usr/local/lib/librocksdb.dylib
-- Found rocksdb 4.1 in /usr/local/include;/usr/local/lib/librocksdb.dylib
-- Configuring incomplete, errors occurred!
See also "/Users/erg/noise/build/CMakeFiles/CMakeOutput.log".
See also "/Users/erg/noise/build/CMakeFiles/CMakeError.log".
ergmac:build erg$ [master*]



ergmac:build erg$ [master*] cmake --version
cmake version 3.4.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).
ergmac:build erg$ [master*]

set(MONSTEER_DESCRIPTION
"Interactive Supercomputing: Monitoring and Steering for NEST simulations") caused issues with documentation repositories.

In doc repo, in "_projects" folder, generated "project.md" file headers are corrupted because github doc server thinks ":" is describing a key:value pair.

Setup:

• desktopstreamer system package installed (/usr/share/Deflect/CMake/DeflectTargets.cmake correctly indicated a dependency of DeflectQt on Qt5::Quick)
• meta-project with:
  git_subproject(Deflect https://github.com/BlueBrain/Deflect.git 0d10736)
  git_subproject(Tide https://github.com/BlueBrain/Tide.git 907ba3b)

Fails to configure with:

CMake Error at CMake/common/CommonLibrary.cmake:112 (add_library):
  Target "TideMaster" links to target "Qt5::Quick" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?
Call Stack (most recent call first):
  Tide/tide/master/CMakeLists.txt:192 (common_library)
[... multiple occurencies ....]

Just removing the first git_subproject(Deflect), or configuring Tide independently, or uninstalling the Deflect system package all work around the problem.

When trying to build ZeroEQ, I'm getting a linking error (zmq refs not found). Debugging it I found that the pkg_check_modules is setting libzmq_LIBRARIES instead of LIBZMQ_LIBRARIES used in ZeroEQ/tests/CMakeLists.txt.

In file CommonGraph.cmake change 21 line:

include(CommonTarget)
=>
include(${CMAKE_CURRENT_LIST_DIR}/CommonTarget.cmake)

Otherwise, it won`t work(

Hi,

I have tried to generate doxygen documentation of a project using the command make prj-doxygen and got this error:

Scanning dependencies of target doxygen_install_prj
-- Install configuration: "Debug"
CMake Error at cmake_install.cmake:36 (file):
  file cannot create directory: /usr/share/prj/CMake.  Maybe need
  administrative privileges.

This error appears because cmake is trying to execute a "make install" before of building the documentation. Since I don't have declared the CMAKE_INSTALL_PREFIX variable, it tries to do an install into my /usr/ directory. Opppps!

As a workaround, I have defined CMAKE_INSTALL_PREFIX to a temporal directory, which is enough to go ahead and build the doxygen documentation under {PROJECT_BINARY_DIR}/doc.

I have peek into file DoxygenRule.cmake and found that there is a DEPENDS at line 125:

add_custom_target(${PROJECT_NAME}-doxygen
  ${DOXYGEN_EXECUTABLE} ${DOXYGEN_CONFIG_FILE}
  WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/doc
  COMMENT "Generating ${PROJECT_NAME} API documentation using doxygen" VERBATIM
DEPENDS ${PROJECT_NAME}-install project_info_${PROJECT_NAME})

Why do you need to install the project before of building the documentation?
It is safe to remove that dependency?

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.

It was only used by CommonDocumentation.cmake which was moved there

Doxygit.cmake is executed using the script present at the project including the CMake tree, but it requires another CMake tree present and the documentation target directory.
This is not very intuitive. It seems more a problem of how CMAKE_SOURCE_DIR is substituted when Doxygit.cmake is executed than the intended behaviour.

Commit d33b31f changes the interface of add_clangcheck() – again. Previously, the syntax seems to have been

add_clangckeck(<target-name>
    [UNUSED_FUNCTIONS]
    [STYLE]
    [POSSIBLE_ERROR]
    [FAIL_ON_WARNINGS]
    [EXCLUDE_PATTERN <pattern>])

, but now it is

add_clangcheck(<target-name> <excluded-files-array>)

and documented as

add_clangcheck(<target-name>
    [UNUSED_FUNCTIONS]
    [STYLE]
    [POSSIBLE_ERROR]
    [FAIL_ON_WARNINGS])

This means that an invocation such as add_clangeck(mytarget) is no longer valid, and fails with the rather unhelpful error

CMake Error at <redacted>/CMakeLists.txt:24 (add_clangcheck):
  add_clangcheck Function invoked with incorrect arguments for function
  named: add_clangcheck

. Please either drop clangcheckTargets from the documented public interface in the README of this repository, or commit to a stable-ish, correctly documented, and backwards-compatible interface.

If backwards compatibility is not your thing, it might be worth marking known-good states as a release and encouraging users to clone that, rather than tracking master as suggested in the README:

[...]To use it, create a .gitexternals file in your project:

# -*- mode: cmake -*-
# CMake/common https://github.com/Eyescale/CMake.git master

Copy GitExternal from this repository to CMake/, and use it in your top-level CMakeLists.txt as follows:

list(APPEND CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/CMake
                              ${CMAKE_SOURCE_DIR}/CMake/common)
include(GitExternal)
include(Common)

This will clone the latest version of this repository into your project at the beginning of the CMake run, and make all its features available. Run the 'update' target after the first successful cmake run to pin the git external to a SHA1 tag instead of a moving master tag.

(Which update target? Maybe my real problem is that I can't figure out how to do that…)

Hi,
I am experiencing the following "issue". In the same project, using CMake/common, I have two libraries lib1 and lib2, and lib2 depends on lib1. Each library has its own directory with its own CMakeLists.txt. Now, when touching the lib1/CMakeLists.txt, both libraries rebuilt/relinked as expected, but when touching lib2/CMakeLists.txt, again both libraries get rebuilt, when only lib2 should be affected. I have tried in a small project with and without CMake/common and this only happens with the latter.

Could it be related to version.{h,cpp} being regenerated when touching any of the CMakeLists.txt files?

Any ideas on how to avoid this?
Thanks!

When building GLEW with MinGW, the GLEWmx library is not found by FindGLEW_MX.cmake.

The build instructions for GLEW [1] suggest to set the SYSTEM variable when calling make. One of the possible values is mingw, where the library base name is glew32 [2]. This causes the multi context library to be built under the name libglew32mx.dll.a which is not found by the CMake module.

I suggest adding a library name to FindGLEW_MX.cmake like so:

diff --git a/FindGLEW_MX.cmake b/FindGLEW_MX.cmake
index 19e3a58..31aaa50 100644
--- a/FindGLEW_MX.cmake
+++ b/FindGLEW_MX.cmake
@@ -11,7 +11,7 @@ find_path(_glew_mx_INCLUDE_DIR GL/glew.h
   /usr/include /usr/local/include /opt/local/include)

 find_library(_glew_mx_LIBRARY
-  NAMES GLEWmx GLEW glew glew32
+  NAMES GLEWmx glew32mx GLEW glew glew32
   PATHS /usr/lib /usr/local/lib)

 if(_glew_mx_INCLUDE_DIR AND _glew_mx_LIBRARY)

For the time being, I created the link libGLEWmx.dll.a which points to libglew32mx.dll.a as a workaround.

Cheers,
Michael

[1] http://glew.sourceforge.net/build.html
[2] http://sourceforge.net/p/glew/code/ci/glew-1.10.0/tree/config/Makefile.mingw

When used within Buildyard, the finder returns

FATAL_ERROR:MAYA_ROOT_DIR is NOT found

I guess that's a typo, but even then it should not exit fatally, but consider QUIET instead.

Reported by @bweyers: when doing find_package(Lunchbox), zeqConfig.cmake uses common_package, which is unknown to external projects:

CMake Error at C:/Users/Christian/Desktop/zeq/build/Lunchbox/LunchboxConfig.cmake:26 (common_package):
  Unknown CMake command "common_package".