I had a similar problem, and resolved it using Paul's answer as a hint. I needed to use python2.7 to compile an older library, but cmake keeps picking up my python3.2 libraries (and executable).
First, I ran cmake with default options, then edited the CMakeCache.txt file which it generated. I did it this way primarily because I didn't know the proper -D... incantations to cause cmake to get the python library and include paths, etc right in the first place.
In my CmakeCache.txt, I found lines like this
Path to a program
PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python
Path to a directory
PYTHON_INCLUDE_DIR:PATH=/usr/include/python3.2
Path to a library
PYTHON_LIBRARY:FILEPATH=/usr/lib/libpython3.2.so
And replaced every occurrence of python3.2 with python2.7. I also had to rename the PYTHON_EXECUTABLE to use python2.7, since python is a symlink to python3.2 on my system.
Then I reran cmake. Because it prefers its cached values to actually looking for the libraries, this should work in all cases. At least, it did in mine.
This module looks preferably for version 3 of Python. If not found,
version 2 is searched. To manage concurrent versions 3 and 2 of
Python, use FindPython3 and FindPython2 modules rather than this one.
My use case was a rather large project in which C++ classes were made available to Python scripts via Boost.Python. After having fought the various quirks of CMake's Python interpreter and library detection, I finally gave up and rolled my own. My approach is based on a slightly after-edited version of the python-config script that is sometimes (but not always!) put into a newly created virtual environment (see this SO post on pyvenv for these issues, but I digress). This script is invoked by a small CMake snippet pyconfig.cmake. Both are freely available from the GitHub repo cmake-python-config.
Warning: The scripts assume that you have a Python 3 interpreter in your PATH. Detection of Python 2 is not attempted. The scripts do not attempt to find all installed versions of Python3 either.