Review Request 110962: Switch to an external LibRaw

[Gilles Caulier]

2013/7/8 Pino Toscano <pino at kde.org>:
> Alle lunedì 8 luglio 2013, Gilles Caulier ha scritto:
>> 2013/7/8 Pino Toscano <pino at kde.org>:
>> > Alle domenica 7 luglio 2013, Gilles Caulier ha scritto:
>> >> > On July 4, 2013, 11:15 a.m., Pino Toscano wrote:
>> >> > > Ping. Gilles, can we please get rid of this libraw copy?
>> >> >
>> >> > Gilles Caulier wrote:
>> >> >     I'm here...
>> >> >
>> >> >     In one week, it's holidays time for me (3 weeks). I will
>> >> >     review this entry in-deep in mid-july
>> >> >
>> >> >     Gilles Caulier
>> >>
>> >> Pino,
>> >>
>> >> I propose to create a libkdcraw branch, based to git/master and to
>> >> to apply your patch. This will be more easy to review and fix
>> >> before to switch this branch in production.
>> >>
>> >> Also, just receive libraw 0.15.3 to apply on master. We can sync
>> >> your branch easily with git.
>> >
>> > There, "external-libraw".
>> >
>> > Note that libraw and extra cmake files are not (and will not)
>> > removed in that branch, to ease the eventual merging from master.
>>
>> And no files must be removed for the moment.
>>
>> Using an external libraw must be optional in this condition :
>>
>> 1/ check if external version is available on the system.
>> 2/ check if it's 0.15.x version.
>>
>> if 1/ and 2/ and respected, well compile and link against shared
>> version.
>>
>> ...else print a warning and indicate that internal version will be
>> used.
>
> Again keeping using internal stuff? Please, pretty please, get out of
> the mindset that using a copy of an external library is a good thing,
> because it is plain wrong.
>
> I'll be even more clearer than what I said in the review request: the
> copy of libraw inside libkdcraw must go away, ASAP.
>
>> As libraw still in early stage of development, i would to preserve
>> internal version until official 1.x release, to be able to test and
>> report quickly all problem to libraw team.
>
> Please explain how using an external version hinders testing, rather it
> is the other way round.
>
> Using an embedded copy means people could use "two versions" of the same
> libkdcraw, one using a system libraw and the other using the external
> version. Considering how things go in such cases (also when looking at
> the history of your own handling of copies of libraries), we would run
> into situations like this: fixes are made into the embedded copy, users
> using the system version report issues and those get fixed because "the
> fix has been imported into the embedded copy" or other stuff like
> this... been there, done that, please do not get into this situation,
> really.
>

As i already explained previously, i DONT want to switch fully to
libraw external support. This must be in 2 stages : 1/ with both until
1.0 and only with an external dependency after this libraw release.

1/ libraw still under development, and we contribute (digiKam team) to
libraw project. To have libraw directly in libkdcraw simplify
development workflow. I other it safe time, and time is precious.

2/ libkdcraw don't include only libraw core but also GPL2 and GPL3
extension which are not include by default in libraw. How to be sure
that all extensions are included in shared lib ? Because it's not the
case, i'm sure to see a lots of bug reports about. These extension
includes several important features that cannot be dropped as well,
due to packaging rules...

3/ libkdcraw include to RawSpeed code which is not included to libraw
and not released yet as shared lib. For the moment this dependency is
optional, but in the future this must be different.

To resume : libraw & co are a complex puzzle. If we switch directly to
your patch, digiKam users will crying.
So we need transition stage to be sure that nothing is lost for end users...

Gilles Caulier