On 06/29/2015 09:41 PM, Mark Moll wrote: > I have attached an alternative module that replaces the two current > modules for finding python-related info. With the current modules > it is easy to end up in a situation where the interpreter’s version > and the library version do not match, which inevitably leads to problems.
Thanks for working on this. The need for a combined module has come up a few times. The main reason it has not been done is because designing a combined module that meets all the use cases of the current two modules and deals with Python 2 and 3 is likely very tricky. Overall my main concern is that no logic from the existing modules is used in the proposed module. The existing modules have worked for many projects for years and have a lot of knowledge built into them. If we combine FindPythonInterp and FindPythonLibs then the results should be similar to finding both packages individually. The combined module should check/validate COMPONENTS requested in the call to find_package. There could be Interp and Libs components such that the package can be found if one component is requested and the other is not available. When I've seen the need for a combined module discussed before, one issue that is commonly raised is that there should be separate FindPython2 and FindPython3 modules because the two languages are somewhat different and some projects may need to find both. Then there could also be a FindPython that accepts either version for projects that can support either. I'm not sure how variables should be named in each of the three modules, but their implementations should share as much code as possible. Further comments on the specific module implementation follow, though with the design requirements laid out above I doubt much of the code will be used as-is. I think this thread should first focus discussion on interface design and not work on the actual code yet. Thanks, -Brad --------------------------------------------------------------------- Currently the module depends on running the python executable. This can be allowed but cannot be required. The module must be able to work when cross-compiling where the libraries come with an executable that may not run on the host. Please read the cmake-developer(7) documentation on find modules: http://www.cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#find-modules In particular please use the proper naming convention for cached v. result variables. Also the module documentation needs to have proper .rst formatting. The PYTHON_EXEC variable should be called PYTHON_EXECUTABLE. (This may change depending on the v2/v3 discussion above.) For find_python_module, please provide documentation of the function using the .rst markup and ".. command::" directive. Also please look at using CMakeParseArguments rather than custom ARGC testing. --------------------------------------------------------------------- -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
