Review Request 110962: Switch to an external LibRaw

[Vadim Zhukov]

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



cmake/modules/FindLibRaw.cmake
<http://git.reviewboard.kde.org/r/110962/#comment25085>

    LIBRAW_DEFINITIONS should be mentioned at the top of the CMake module then. Also, they should be cached, or they'll lost after initial configure stage, causing problems on re-configure.



cmake/modules/FindLibRaw.cmake
<http://git.reviewboard.kde.org/r/110962/#comment25082>

    HINTS should be more appropriate here than PATHS, no? From CMake manual:
    
    "... paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option."
    
    Same applies to the find_library() call.



cmake/modules/FindLibRaw.cmake
<http://git.reviewboard.kde.org/r/110962/#comment25084>

    This check looks ugly. LibRaw itself provides LIBRAW_CHECK_VERSION() macros (in libraw_version.h), which could be used in compile check. This way it should be more future-compatible than parsing header file itself.


- Vadim Zhukov


On June 11, 2013, 9:50 p.m., Pino Toscano wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110962/
> -----------------------------------------------------------
> 
> (Updated June 11, 2013, 9:50 p.m.)
> 
> 
> Review request for KDE Graphics, Release Team and Gilles Caulier.
> 
> 
> Description
> -------
> 
> Instead of using an embedded copy of LibRaw, look for an external LibRaw as mandatory dependency with a new CMake module and using its variables.
>     
> Considering some LibRaw versions seem to be underlinked and not linking to OpenMP, link it manually in libkdcraw to overcome such lack.
>     
> Switch back to the MAKE_KDCRAW_LIB define (i.e. the default set by KDE4_ADD_LIBRARY) as the one used to check whether it is being built, as otherwise LIBRAW_BUILDLIB would conflict with LibRaw.
> 
> Once this RR is approved, I will remove the libraw code copy and the CMake modules (FindLCMS2.cmake and FindPthreads.cmake) needed for it.
> 
> 
> This addresses bug 307146.
>     http://bugs.kde.org/show_bug.cgi?id=307146
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt f2f269609feb10947ec3bac10125b379c6c821dd 
>   cmake/modules/FindLibRaw.cmake PRE-CREATION 
>   libkdcraw/CMakeLists.txt cce5d6dba690fb5182638ccd1f10488bbd6ec2ce 
>   libkdcraw/libkdcraw_export.h 1a222a03502a0e068bdba4f03b7ff4961c4a8f2b 
> 
> Diff: http://git.reviewboard.kde.org/r/110962/diff/
> 
> 
> Testing
> -------
> 
> Compiles fine with both LibRaw 0.14.7 and 0.15.1.
> 
> 
> Thanks,
> 
> Pino Toscano
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130611/3ce93cf2/attachment-0001.html>