Brad, Thanks for the detailed explanation. I figured there were use cases not handled by my module. For instance, I hadn’t thought of cross-compilation. Since in my own project these unhandled cases haven't come up, I’ll stick with own module for now.
With the existing modules it might be useful to add a check that if both PYTHON_VERSION_STRING and PYTHONLIBS_VERSION_STRING are defined, then they should be equal. Best, Mark > On Jun 30, 2015, at 9:02 AM, Brad King <[email protected]> wrote: > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 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
