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

[Andreas Pakulat]

On 20.10.11 14:12:10, Alastair McKinstry wrote:
> 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.

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