extragear/libs [POSSIBLY UNSAFE]

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

extragear/libs [POSSIBLY UNSAFE]

Gilles Caulier-2
SVN commit 632867 by cgilles:

kipi-plugins from trunk : starting new shared library "libkdcraw" based on digiKam core and RAW converter implementations.

This library will provide a C++ interface to dcraw command line program to decode RAW pictures. It will be used by digiKam and kipi-plugins. A common implementation is require to prevent duplicate source code.

The library is not yet complete. I'm working on actually. Compilation is disable by default. Future digiKam 0.9.2 release will use it.

CCMAIL: [hidden email], [hidden email], [hidden email]

 A             libkdcraw (directory)  
 A             libkdcraw/AUTHORS  
 A             libkdcraw/COPYING  
 A             libkdcraw/ChangeLog  
 A             libkdcraw/INSTALL  
 A             libkdcraw/Makefile.am  
 A             libkdcraw/NEWS  
 A             libkdcraw/README  
 A             libkdcraw/configure.in.bot  
 A             libkdcraw/configure.in.in  
 A             libkdcraw/dcraw (directory)  
 A             libkdcraw/dcraw/Makefile.am  
 A             libkdcraw/dcraw/README  
 AM            libkdcraw/dcraw/dcraw.c   [POSSIBLY UNSAFE: scanf] [License: GENERATED FILE]
 AM            libkdcraw/dcrawbinary.cpp   [License: GPL]
 AM            libkdcraw/dcrawbinary.h   [License: GPL]
 A             libkdcraw/libkdcraw.lsm  
 A             libkdcraw/libkdcraw.pc.in  
 AM            libkdcraw/libkdcraw_export.h   [License: GPL]
 AM            libkdcraw/rawfiles.h   [License: GPL]
 AM            libkdcraw/version.h   [License: GPL]


** trunk/extragear/libs/libkdcraw/dcraw/dcraw.c #property svn:eol-style
   + native
** trunk/extragear/libs/libkdcraw/dcrawbinary.cpp #property svn:eol-style
   + native
** trunk/extragear/libs/libkdcraw/dcrawbinary.h #property svn:eol-style
   + native
** trunk/extragear/libs/libkdcraw/libkdcraw_export.h #property svn:eol-style
   + native
** trunk/extragear/libs/libkdcraw/rawfiles.h #property svn:eol-style
   + native
** trunk/extragear/libs/libkdcraw/version.h #property svn:eol-style
   + native
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: extragear/libs [POSSIBLY UNSAFE]

Fabien-5
Hello,

Gilles Caulier wrote:
> SVN commit 632867 by cgilles:
>
> kipi-plugins from trunk : starting new shared library "libkdcraw"
> based on digiKam core and RAW converter implementations.
>
> This library will provide a C++ interface to dcraw command line
> program to decode RAW pictures. It will be used by digiKam and
> kipi-plugins. A common implementation is require to prevent duplicate
> source code.

I was thinking about something related to these "small" libraries (also
libkexiv2)...

Wouldn't it be possible to just use a external reference in svn :
http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
in order to avoid duplicate code, instead of adding more complexity
(dependency problems, versions mismatch and so on) ?

Just an idea :)

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: extragear/libs [POSSIBLY UNSAFE]

Gilles Caulier-2
Le mardi 13 février 2007 10:19, Fabien a écrit :

> Hello,
>
> Gilles Caulier wrote:
> > SVN commit 632867 by cgilles:
> >
> > kipi-plugins from trunk : starting new shared library "libkdcraw"
> > based on digiKam core and RAW converter implementations.
> >
> > This library will provide a C++ interface to dcraw command line
> > program to decode RAW pictures. It will be used by digiKam and
> > kipi-plugins. A common implementation is require to prevent duplicate
> > source code.
>
> I was thinking about something related to these "small" libraries (also
> libkexiv2)...
>
> Wouldn't it be possible to just use a external reference in svn :
> http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
> in order to avoid duplicate code, instead of adding more complexity
> (dependency problems, versions mismatch and so on) ?
>
> Just an idea :)

no, because kipi-plugins must be independant of digiKam core. You cannot link
it with a svn-link source code witch point to digiKam core

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: extragear/libs [POSSIBLY UNSAFE]

Colin Guthrie-6
Caulier Gilles wrote:
> no, because kipi-plugins must be independant of digiKam core. You cannot link
> it with a svn-link source code witch point to digiKam core

I think Fabien was talking about svn:external rather than a symbolic link.

The libraries could exist in their own SVN path but just be referenced
via and svn:external to check it out automatically, and thus be build
locally into each package, but avoid the need to do separate releases.

This would complicate things a little in other areas, but probably not
more so than currently ;)

FYI: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html

Col

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: extragear/libs [POSSIBLY UNSAFE]

Fabien-5
Colin Guthrie wrote:

> Caulier Gilles wrote:
>
>>no, because kipi-plugins must be independant of digiKam core. You cannot link
>>it with a svn-link source code witch point to digiKam core
>
>
> I think Fabien was talking about svn:external rather than a symbolic link.
>
> The libraries could exist in their own SVN path but just be referenced
> via and svn:external to check it out automatically, and thus be build
> locally into each package, but avoid the need to do separate releases.

Yes, exactly...
My purpose was to avoid a shared library with its problem (releases,
distribution packages with lib an -dev, version conflicts).
For small libraries like that, I guess performance and memory footprint
would not be affected...

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

Re: extragear/libs [POSSIBLY UNSAFE]

Bugzilla from anaselli@linux.it
In reply to this post by Gilles Caulier-2
Alle 16:24, lunedì 12 febbraio 2007, Gilles Caulier ha scritto:
> SVN commit 632867 by cgilles:
>
> kipi-plugins from trunk : starting new shared library "libkdcraw" based on digiKam core and RAW converter implementations.
Gilles that means i have to release libdcraw just before digikam 0.9.1 rc1,
are you sure that was a good idea? I mean I don't know for other distro,
but I'm fighting with libkexiv that should be in our (mandriva) main
repository to have digikam rebuilt, and now i will for libdcraw...
Moreover kipi team have a lot of packages to release, are you sure
that we couldn't release a common image library collection?
Now for exif and raw, tomorrow for any other image format/info...
taht would be easier to maintain and release...

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: extragear/libs [POSSIBLY UNSAFE]

Bugzilla from anaselli@linux.it
In reply to this post by Colin Guthrie-6
Alle 14:07, martedì 13 febbraio 2007, Colin Guthrie ha scritto:

> Caulier Gilles wrote:
> > no, because kipi-plugins must be independant of digiKam core. You cannot link
> > it with a svn-link source code witch point to digiKam core
>
> I think Fabien was talking about svn:external rather than a symbolic link.
>
> The libraries could exist in their own SVN path but just be referenced
> via and svn:external to check it out automatically, and thus be build
> locally into each package, but avoid the need to do separate releases.
>
> This would complicate things a little in other areas, but probably not
> more so than currently ;)
>
> FYI: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
Col that could be a good idea for developers, and svn version testers.
I don't know if Fabien thought only about that, but if we're talking about
library dependency well that problem remains since those libraries can only
be external and shared. That is the only way to share that code between more than
one project without linking it statically or changing the library names.

Am i wrong?

Angelo

P.S. (I like your idea though, I believe I'll use in a project at work ;) )

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

attachment0 (196 bytes) Download Attachment