[CMake] Empty ./CMakeFiles/Makefile2 - how to proceed?
I'm building a debian package, CDAT http://bugs.debian.org/584637. The latest version 6.0.alpha uses CMAKE to build, rather than configure. The trouble is that CMake doesn't build. It doesn't even fail. $ mkdir build $ cd build $ cmake .. ()-- Configuring done -- Generating done -- Build files have been written to: /home/amckinstry/deb-packages /cdat/cdat-6.0.alpha/build $ make $ The problem is, 'make' does nothing. A Makefile is generated by CMake, which calls cmake which calls make again on /./CMakeFiles/Makefile2/ ... which does nothing useful. Apparently the CMake is supposed to put useful stuff in there, but doesn't. What puts stuff into Makefile2, and where should I pick up the bugs trail? -- Alastair McKinstry ,alast...@sceal.ie ,mckins...@debian.org http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Empty ./CMakeFiles/Makefile2 - how to proceed?
2011/10/20 Alastair McKinstry mckins...@debian.org: I'm building a debian package, CDAT. The latest version 6.0.alpha uses CMAKE to build, rather than configure. The trouble is that CMake doesn't build. It doesn't even fail. $ mkdir build $ cd build $ cmake .. ()-- Configuring done -- Generating done -- Build files have been written to: /home/amckinstry/deb-packages /cdat/cdat-6.0.alpha/build $ make $ The problem is, 'make' does nothing. A Makefile is generated by CMake, which calls cmake which calls make again on ./CMakeFiles/Makefile2 ... which does nothing useful. Apparently the CMake is supposed to put useful stuff in there, but doesn't. What puts stuff into Makefile2, and where should I pick up the bugs trail? CMake is not a build tool like make is, it is a build tool **generator**. Thus, CMake generates the Makefile files (including ./CMakeFiles/Makefile2) during the $ cmake .. step. The inputs of CMake are files named CMakeLists.txt, those files are the equivalent of Makefile files for make with a more declarative syntax. However if this CDAT package does not build correctly out-of-the-box you'd better ask to the package provider first. They must but the authors of their CMake usage. If they have trouble with CMake, then they can ask question here. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Empty ./CMakeFiles/Makefile2 - how to proceed?
On 2011-10-20 13:43, Eric Noulard wrote: 2011/10/20 Alastair McKinstrymckins...@debian.org: I'm building a debian package, CDAT. The latest version 6.0.alpha uses CMAKE to build, rather than configure. The trouble is that CMake doesn't build. It doesn't even fail. $ mkdir build $ cd build $ cmake .. ()-- Configuring done -- Generating done -- Build files have been written to: /home/amckinstry/deb-packages /cdat/cdat-6.0.alpha/build $ make $ The problem is, 'make' does nothing. A Makefile is generated by CMake, which calls cmake which calls make again on ./CMakeFiles/Makefile2 ... which does nothing useful. Apparently the CMake is supposed to put useful stuff in there, but doesn't. What puts stuff into Makefile2, and where should I pick up the bugs trail? CMake is not a build tool like make is, it is a build tool **generator**. Thus, CMake generates the Makefile files (including ./CMakeFiles/Makefile2) during the $ cmake .. step. The inputs of CMake are files named CMakeLists.txt, those files are the equivalent of Makefile files for make with a more declarative syntax. However if this CDAT package does not build correctly out-of-the-box you'd better ask to the package provider first. They must but the authors of their CMake usage. If they have trouble with CMake, then they can ask question here. Thanks. I understand that CMake is a build tool generator, and have worked with it in several other packages. The difficulty here is that I need to adapt the build process from upstream to debian standards Specifically, the upstream build process updates itself from git, downloads third party tarballs, applies patches, puts files in non-standard directories, etc. This breaks the concept in Debian of known reliable builds, no embedded copies of libraries, etc, so that the security team don't have to check 13000 packages for embedded copies of libfoo if a bug is found, etc. .. This means that I am doing stuff that is unsupported by upstream. Fair enough. I understand that the package is defined in CMakeLists.txt , its includes, etc. When i've encountered problems before I have backtracked from the error message to the bit there that caused the problem. The trouble I am having today is that now I need to understand _how_ CMake goes from CMakeLists.txt to the generated ./build/CMakeFiles/Makefile2 file. As its not failing, I have no error thread to follow, and need a deeper understanding of CMake than the simple tutorials I've found on the web. Is there documentation on the 'innards' of CMake? best regards Alastair -- Alastair McKinstry ,alast...@sceal.ie ,mckins...@debian.org http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Empty ./CMakeFiles/Makefile2 - how to proceed?
On 20.10.11 14:12:10, Alastair McKinstry wrote: On 2011-10-20 13:43, Eric Noulard wrote: 2011/10/20 Alastair McKinstrymckins...@debian.org: I'm building a debian package, CDAT. The latest version 6.0.alpha uses CMAKE to build, rather than configure. The trouble is that CMake doesn't build. It doesn't even fail. $ mkdir build $ cd build $ cmake .. ()-- Configuring done -- Generating done -- Build files have been written to: /home/amckinstry/deb-packages /cdat/cdat-6.0.alpha/build $ make $ The problem is, 'make' does nothing. A Makefile is generated by CMake, which calls cmake which calls make again on ./CMakeFiles/Makefile2 ... which does nothing useful. Apparently the CMake is supposed to put useful stuff in there, but doesn't. What puts stuff into Makefile2, and where should I pick up the bugs trail? CMake is not a build tool like make is, it is a build tool **generator**. Thus, CMake generates the Makefile files (including ./CMakeFiles/Makefile2) during the $ cmake .. step. The inputs of CMake are files named CMakeLists.txt, those files are the equivalent of Makefile files for make with a more declarative syntax. However if this CDAT package does not build correctly out-of-the-box you'd better ask to the package provider first. They must but the authors of their CMake usage. If they have trouble with CMake, then they can ask question here. Thanks. I understand that CMake is a build tool generator, and have worked with it in several other packages. The difficulty here is that I need to adapt the build process from upstream to debian standards Specifically, the upstream build process updates itself from git, downloads third party tarballs, applies patches, puts files in non-standard directories, etc. This breaks the concept in Debian of known reliable builds, no embedded copies of libraries, etc, so that the security team don't have to check 13000 packages for embedded copies of libfoo if a bug is found, etc. .. This means that I am doing stuff that is unsupported by upstream. Fair enough. This sounds as if the package you got from upstream uses ExternalProject (or a homebrewn version of a similar module) for building. If so, somewhere in the cmake-files there would be the 'core' project and it'll be in a ExternalProject_Add line. If you find that it's probably in its own subdirectory and thats the subdir that you want to build. Ignore all the rest. If they're not doing things, your best bet is to talk to upstream to change their build-setup. You won't be able to entangle this unless you have a good idea how their build process works. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
