> On June 11, 2013, 6:38 p.m., Gilles Caulier wrote: > > libraw detection can be not enough. > > > > if you look in libkdcraw, you will see RawSpeed code backported too. > > > > http://rawstudio.org/blog/?p=800 > > > > This code is to speed up raw data extraction. It's not to process > > demosaicing. > > > > Here on my linux Mageia, librawspeed is not available. I don't know if > > other distro support this library. > > > > LibRaw < 0.15 will not support RawSpeed. You must take a care about. In > > this case RawSpeed must be disabled. > > > > Also, settings from raw decoding container and widget have been validated > > with libraw 0.15.x. So do not accept an older version of libraw, else there > > will be serious problems... > > > > Gilles Caulier > > Pino Toscano wrote: > > if you look in libkdcraw, you will see RawSpeed code backported too. > > Yet another copy of some 3rd party source?! Sigh.... It would be really > helpful if your development way would not start by embedding some 3rd party > library in the sources of some KDE application/library... > > For the rest: OK, it is fine to accept only LibRaw >= 0.15. (I suspect > they would work the same, but oh well...) > > Gilles Caulier wrote: > The reason to include libraw is simple : libraw API change agian and > again, and i don't won't to puzzle libkdcraw source code with an amount of > conditional rules. As i'm in contact with libraw team, i'm aware of plan and > this is why i take a care to not have a shared component as libkdcraw which > provide a broken binary compatibility with a lots of crash... Just my > experience. > > Typicially, libraw as experiental code which are tested and removed if to > much problem are reported... > > There is also another problem : how to be sure that 3rd party codec from > libraw are compiled in shared version of system : There are 2 packs : one > GPL2, one GPL3. These packages add new demosaicing methods and camera > support. If libraw is not compiled with these components some parts of > libkdcraw will not work as well. This will be very problematic for end > users... > > This is another reason about libraw inclusion in libkdcraw. Like this i'm > sure that all features are included... > > Libraw is a big puzzle. Take a care... > > Gilles Caulier > > Pino Toscano wrote: > If the API changes, then the version macros can be used to keep > compatibility with multiple versions; it seems the libraw people are not > breaking the API much lately, so hopefully the libkdcraw code won't be filled > with a lot of these checks. > > Regarding the binary compatibility: if the libraw people bump > SONAME/SOVERSION whenever the ABI changes, that's perfectly fine and will not > cause issues (maybe just to self-compiling users which have no clue on what > they are doing). If they break ABI without handling SONAME/SOVERSION bumps, > that's their fault which they ought to solve. > > Regarding the extra packs: are those compiled/provided by default to > libraw users? If they could cause licensing issues/incompatibilities, then > compiling them as part of libkdcraw will *not* change their situation. > > Gilles Caulier wrote: > Extra GPL2/GPL3 pack are not included in libraw in standard due to mixing > licensing problem. It's separated packages. So distro packagers must take a > care about and compile all as well. > > It's the same problem with RawSpeed which use another licensing than > libraw core... > > Gilles Caulier > > Pino Toscano wrote: > So the inclusion of these packs in libkdcraw *is* creating a licensing > issue to distro packagers already? Great... > > Gilles: putting everything in one source (libkdcraw) does not make > a) licensing issues > b) incompatibilities > c) shipping issue > go away at the same time, as you're creating new issues instead. > > Now, if you could help testing this in the way you like, we could cleanup > all this embedding mess in libkdcraw. Thank you.
>go away at the same time, as you're creating new issues instead. Certainly not ! I creating something which work as we can with this big puzzle. It's work, and it's my first priority. Licensing problem is another stuff. It's not a technical issue. Don't mix everything... Gilles Caulier - Gilles ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110962/#review34173 ----------------------------------------------------------- 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 > >
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
