unifying libdiff2

[Jeremy Whiting]

Hello all,

Since kdesdk has now safely migrated from svn to git, I thought it would be
a good time to get this ball rolling again.  I just reread this thread and
would like to suggest the following:

1. Move libdiff2 out of kompare.git into it's own git repository just
within kdesdk on projects.kde.org
2. Make sure libdiff2 installs header files and CMakeConfig file, etc. so
it can be easily used by kompare, okteta, kdevplatform patchreview plugin,
and anything else that wants to use it. (Not sure if this is already the
case, Kevin or Konstantin, you guys would know better, or I can investigate)
3. Make kdevplatform patchreview plugin use the new libdiff2 that has
everything properly exposed.
4. Review the difference between the two copies of libdiff2 to see if any
changes in the kdevplatform copy should be merged into the main one in
kdesdk
And lastly, nuke the libdiff2 folder in kdevplatform.git

Suggestions, questions, or answers to any of the above welcome.

thanks,
Jeremy


On Sun, Dec 11, 2011 at 2:54 PM, Aleix Pol <aleixpol at kde.org> wrote:

> Hi Jeremy,
> What's the status on this one?
>
> Aleix
>
>
> On Sat, Oct 29, 2011 at 5:35 PM, David Nolden <
> david.nolden.kdevelop at art-master.de> wrote:
>
>> I was the one who once forked libdiff2 many years ago (probably around
>> 2007 or so), and it was mainly for comfort reasons, because libdiff2
>> would have needed a quite big refactoring to be nicely usable by both
>> Kompare and KDevelop:
>> * libdiff2 was a static library living in a subdirectory of the at
>> that time unmaintained kde4 kompare port
>> * libdiff2 contained a lot of UI code, while we were only interested
>> in the 'model' code (that's why I commented out quite a bit of stuff)
>>
>> While it is nice to share some code, I'm also not in favor of adding
>> huge dependencies like 'whole kdesk'.
>>
>> Having the code shared can also make life significantly harder
>> regarding changes in the library: How should the correct versions of
>> the library and the application be synced together? We experience this
>> again and again through the split between kate and kdevelop. Therefore
>> we should ask the question whether KDevelop and Kompare really have so
>> much in common, that they will actually _profit_ from each others
>> potential future improvements in a shared libdiff2. The word 'fork' is
>> often interpreted more evil than it actually is. ;-)
>>
>> Greetings, David
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kompare-devel/attachments/20130709/e81f3008/attachment.html>