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

[Florent Castelli]

I just want to add that I also saw a colleague running in the issue
described in the beginning of the thread and that the version reported by
the Python module and the PythonLibs one were different strings, even
though the version was actually the same. It happened on latest Debian I
think.

How I discovered it? I had a check in my CMakeLists.txt that ensured the
strings were identical. It's the first time in years we saw it fail.

/Florent

On Tue, Jun 30, 2015 at 4:14 PM, Mark Moll <mmoll at rice.edu> wrote:

> 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
>
>
> --
>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150630/e58d537e/attachment-0001.html>