Review Request 110962: Switch to an external LibRaw

[Pino Toscano]

> On June 11, 2013, 6:03 p.m., Vadim Zhukov wrote:
> > cmake/modules/FindLibRaw.cmake, line 19
> > <http://git.reviewboard.kde.org/r/110962/diff/1/?file=149621#file149621line19>
> >
> >     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.

Will fix.


> On June 11, 2013, 6:03 p.m., Vadim Zhukov wrote:
> > cmake/modules/FindLibRaw.cmake, line 23
> > <http://git.reviewboard.kde.org/r/110962/diff/1/?file=149621#file149621line23>
> >
> >     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.

Will change.


> On June 11, 2013, 6:03 p.m., Vadim Zhukov wrote:
> > cmake/modules/FindLibRaw.cmake, line 36
> > <http://git.reviewboard.kde.org/r/110962/diff/1/?file=149621#file149621line36>
> >
> >     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.
> 
> Rolf Eike Beer wrote:
>     I bet that macro is a C macro, not a CMake one. So for finding out in CMake code which version was found this doesn't help.

Yes, I know about the macros in libraw_version.h, but they cannot be used at all in version checks at CMake time. Currently, the version string is just printed, but in the future it might be used to force a minimum version.


- Pino


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


On June 11, 2013, 5: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, 5: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/50e5f329/attachment.html>