Review Request 110954: Rewrite FindBoostPython.cmake for correctness and stability

Vadim Zhukov persgray at gmail.com
Thu Jun 20 08:35:37 UTC 2013



> On June 12, 2013, 6:02 p.m., David Narváez wrote:
> > Can you comment on the minimum CMake version required to use find_package_handle_standard_args() and cmake_push_check_state()/cmake_pop_check_state()? IIUC, FindKDE4Internal sets the minimum required to 2.8.9 so we need to check if that is a problem.

find_package_handle_standard_args() introduced in CMake 2.8, cmake_push_check_state()/cmake_pop_check_state - in CMake 2.8.5. They are more and more used in other KDE modules already.


- Vadim


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110954/#review34222
-----------------------------------------------------------


On June 11, 2013, 7:10 p.m., Vadim Zhukov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110954/
> -----------------------------------------------------------
> 
> (Updated June 11, 2013, 7:10 p.m.)
> 
> 
> Review request for KDE Edu and David Narváez.
> 
> 
> Description
> -------
> 
> 1. Return compile check (see BoostPython_TRY_COMPILE() macro), it's needed for some cases. Say, default Python in system is Python 3.3, and it gets picked up. But Boost 1.53 python library could not work with it and requires Python 2.x. Without compile check you'll pick up uncompatible Python version.
> 
> 2. find_package(PkgConfig) moved under corresponding if(...) and if(PKG_CONFIG_FOUND) is checked after. While it's spread enough, there is no guarantee you'll have pkg-config on that system. Also, PYTHON_VERSIONS moved closer to the scope where it's used to improve readability.
> 
> 3. Use standard CMake find_package_handle_standard_args() and cmake_push_check_state()/cmake_pop_check_state() instead of rolling own equivalent logic. The latter logic was ever wrong, making HAVE_BOOST_SHARED_PTR_HPP check fail.
> 
> 4. BoostPython_INCLUDE_DIRS and BoostPython_LIBRARIES are saved in cache, as other CMake modules do. This unbreaks the situation when CMake detects that it should be re-run (for example, some CMakeLists.txt file was modified), and runs through modules again - in this case, if BoostPython_INCLUDE_DIRS and BoostPython_LIBRARIES are not in cache, all tests will be run again, and probably fail now.
> 
> 
> This addresses bug 320807.
>     http://bugs.kde.org/show_bug.cgi?id=320807
> 
> 
> Diffs
> -----
> 
>   cmake/modules/FindBoostPython.cmake d6c5a34 
> 
> Diff: http://git.reviewboard.kde.org/r/110954/diff/
> 
> 
> Testing
> -------
> 
> OpenBSD-CURRENT, CMake 2.8.11, KDE 4.10.4, Boost 1.53, Python 3.3 and 2.7.
> 
> 
> Thanks,
> 
> Vadim Zhukov
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20130620/45bdb4bb/attachment-0001.html>


More information about the kde-edu mailing list