The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15757 ====================================================================== Reported By: Pavel Solodovnikov Assigned To: ====================================================================== Project: CMake Issue ID: 15757 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2015-09-23 05:28 EDT Last Modified: 2015-09-23 05:28 EDT ====================================================================== Summary: Including a project from parent subdirectory causes CMake to produce wrong build files for Ninja generator Description: Suppose we have following project structure:
testing_ninja/ --- mylib1/ ------ CMakeLists.txt ------ src.cpp --- mylib2/ ------ CMakeLists.txt ------ src.cpp CMakeLists.txt for mylib1 creates a library mylib1.dll, which exports some symbols needed by mylib2, so mylib2 depends on mylib1 ( via target_link_libraries(mylib2 mylib1) ). If mylib1 CMakelists.txt contains following line, which includes mylib2 project: add_subdirectory("../mylib2" "../mylib2") then if we use Ninja generator to produce build files (invoking cmake inside mylib1 directory), the generated build.ninja file contains errors. CMake-generated build.ninja file contains mixed absolute-relative paths for mylib1.lib target which confuses ninja in such a way: when ninja is invoked it immediately reports an error that it couldn't find mylib1.lib binary needed by mylib2 (however it should be generated at build time and ninja should not rely on its existence). Error message is as follows: E:\testing_ninja\mylib1>ninja ninja: error: 'E:/testing_ninja/mylib1/mylib1.lib', needed by 'E:/testing_ninja/ mylib2/mylib2.dll', missing and no known rule to make it As I understand it happens because CMake generates a list of phony targets for each build target (expressed via relative path to target), so ninja does not need these files to exist at the beginning of build. And because CMake is mixing up relative and absolute paths in this case, ninja does not recognize phony targets anymore (they are expressed as absolute paths now) and fails. If I move mylib2 project inside mylib1 directory so the whole source tree stays inside the folder in which the root CMakeLists.txt file is placed, this behavior does not happen. To note one important moment: this only does happen if mylib1 appears to be dynamic library, if we build static libraries instead everything is alright. I've attached a test project to demonstrate such behavior. Tested only on Windows but I assume that it could be reproduced under the same conditions on other platforms. Steps to Reproduce: 1) Extract attached archive 2) Invoke cmake inside mylib1 directory with following arguments: cmake -G "Ninja" . ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-23 05:28 Pavel SolodovnikovNew Issue 2015-09-23 05:28 Pavel SolodovnikovFile Added: testing_ninja.zip ====================================================================== -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers