[cmake-developers] FindPython.cmake alternative for FindPythonInterp.cmake and FindPythonLibs.cmake

[Mark Moll]

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 <brad.king at kitware.com> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150630/2dc8e306/attachment.sig>