[CMake] "Empty" ./CMakeFiles/Makefile2 - how to proceed?

Alastair McKinstry mckinstry at debian.org
Thu Oct 20 09:12:10 EDT 2011


On 2011-10-20 13:43, Eric Noulard wrote:
> 2011/10/20 Alastair McKinstry<mckinstry at 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  ,<alastair at sceal.ie>  ,<mckinstry at 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.




More information about the CMake mailing list