There is no automated tool that will convert an arbitrary build system from autotools to cmake. I have converted a few moderately large projects manually. I like to create one CMakeLists.txt file for each set of configure.ac and/or Makefile.am file, to ease the conversion from autotools to cmake.
Sadly, this manual approach requires developing an expertise in two systems, no one of which should be inflicted on any innocent.
Capture a record of what autotools build actually does on your machine. This will help you verify that your CMake build system actually compiles every file, using the same compile flags, and creates every library and executable that autotools does; at least on your machine, with your options.
% ./configure [configure options] > configure_autotools.log
% make > make_autotools.log
% make install > make_install_autotools.log
In every directory that contains a configure.ac or Makefile.am file, including the project root directory, create a new empty CMakeLists.txt file. Add cmake add_subdirectory(...) commands to each non-leaf CMakeLists.txt file to link all the cmake files together in a tree structure. Add cmake project() and cmake_minimum_required() commands to the top of your top level CMakeLists.txt file.
project(MyProject)
cmake_minimum_required(VERSION 2.8)
add_subdirectory(foo)
You now have a consistent but useless cmake build system that does nothing. Temporarily add a few message(...) commands in the deeper CMakeLists.txt files to verify that everything is connected correctly. Remember that message() is your friend when debugging cmake configuration problems. Make sure your cmake infrastructure works by trying a build now. Nothing will get built or installed; but it is valuable to exercise the cmake infrastructure at this point.
% mkdir build_cmake
% cd build_cmake
% ccmake -i [your project root]
[configure, configure, generate]
% make VERBOSE=1
% make install
This is the hard part. One by one, populate your CMakeLists.txt files. Here are some guidelines:
Open two side-by-side editors, one with the CMakeLists.txt file, the other with the corresponding Makefile.am/configure.ac file.
Have your browser open to the cmake commands documentation.
Rather than starting from the very top, start off by creating cmake rules for building a small library or executable, if you can find one in the project (cmake add_library() or add_executable()). Using this approach you can build up your conversion one piece at a time.
Keep periodically testing your cmake build system as you add each target.
I like to use the cmake file(GLOB ...) command to compactly create lists of source files. Be aware that this is a controversial opinion.
Many common autotools stanzas have corresponding CMake commands. For example autoconf AC_TRY_COMPILE can be converted to cmake TRY_COMPILE. But mostly I find I have to understand what every little autotools stanza does and figure out how to write the corresponding cmake. Also, there is a series of CMake modules that help create autotools-like config.h files. Makefile.am files are often easier to convert, and can actually become more compact after translation to cmake.
Compare your cmake build results to the autotools logs you captured in step 1. Are the compile flags the same? Are all of the same targets built? Are the same files installed?
Unfortunately I have not converted autotools to cmake recently, so I am not in a position to write a comprehensive "if you see x in Makefile.am, write y in CMakeLists.txt". Can someone suggest a good location for a public wiki where folks who are actively converting from autotools to cmake can accumulate a comprehensive set of such guidelines? I'm not sure if this stackoverflow answer is the best place for such a list...
For extra credit, once you have it all working, tweak your cmake rules to be able to build and run your project from Windows Visual Studio. Try that with autotools!
