digikam libs questions

Gilles asked me to send this mail to the ML...


Hi,

I used to program in python all the time, so I'm still quite confused by the
libs mechanism in C++.

I understand that some of the .o files are packed into library files (to save
space and make things easier) and some header files are stored
in /usr/include/digikam to actually access those libs from the program the
libs will be used in.

But what are those DIGIKAM_EXPORT macros for? They seem to be in nearly every
class although not every class seems to be exported into libs (or at least no
header files exist in /usr/include/digikam).

Do they signal gcc to pack those object files into libraries?
I found out that in the main CMakeLists.txt (in digikam root) there are a lot
of libs defined, but in the end only a few of them are actually installed
in /usr/lib. For example we define a libhaar, but I can't find it anywhere.

Maybe those questions are stupid, but I want to understand completely what we
are doing here (in Cmake and in the code as well).
For example my histogrambox widget: I just used copy and paste for it, because
I didn't know what to do at this moment. So it has an EXPORT macro in front
of the class and it also becomes installed in /usr/include, but I guess we
don't need this widget the be accessed from outside of digiKam. So I could
remove it from the INSTALL rule in the CMake file. But if I do so, do I have
to remove the EXPORT macro as well or do I have to keep it.


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

[Patrick Spendrin]

Andi Clemens schrieb:

> Gilles asked me to send this mail to the ML...
>
>
> Hi,
>
> I used to program in python all the time, so I'm still quite confused by the
> libs mechanism in C++.
>
> I understand that some of the .o files are packed into library files (to save
> space and make things easier) and some header files are stored
> in /usr/include/digikam to actually access those libs from the program the
> libs will be used in.
>
> But what are those DIGIKAM_EXPORT macros for? They seem to be in nearly every
> class although not every class seems to be exported into libs (or at least no
> header files exist in /usr/include/digikam).

Exactly. Basically you need one export macro (like DIGIKAM_EXPORT) for
each library you build in the end. The export macro gets set in
digikam/digikam/digikam_export.h to KDE_EXPORT or KDE_IMPORT. The idea
is to restrict the API you expose to the library user by these
functions. They are especially important under Windows, but the current
g++ compilers support visibility as well.

>
> Do they signal gcc to pack those object files into libraries?
> I found out that in the main CMakeLists.txt (in digikam root) there are a lot
> of libs defined, but in the end only a few of them are actually installed
> in /usr/lib. For example we define a libhaar, but I can't find it anywhere.
>
> Maybe those questions are stupid, but I want to understand completely what we
> are doing here (in Cmake and in the code as well).
> For example my histogrambox widget: I just used copy and paste for it, because
> I didn't know what to do at this moment. So it has an EXPORT macro in front
> of the class and it also becomes installed in /usr/include, but I guess we
> don't need this widget the be accessed from outside of digiKam. So I could
> remove it from the INSTALL rule in the CMake file. But if I do so, do I have
> to remove the EXPORT macro as well or do I have to keep it.

yes, of course.
>
>
> Andi
regards,
Patrick

p.s.: if you need a complete explanation of this issue just ask me.
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>


--
web:                 http://windows.kde.org
mailing list:        [hidden email]
irc:                 #kde-windows (irc.freenode.net)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Gilles asked me to send this mail to the ML...
>
>
> Hi,
>
> I used to program in python all the time, so I'm still quite confused by
> the libs mechanism in C++.
>
> I understand that some of the .o files are packed into library files (to
> save space and make things easier) and some header files are stored
> in /usr/include/digikam to actually access those libs from the program the
> libs will be used in.
>
> But what are those DIGIKAM_EXPORT macros for? They seem to be in nearly
> every class although not every class seems to be exported into libs (or at
> least no header files exist in /usr/include/digikam).
>
> Do they signal gcc to pack those object files into libraries?
> I found out that in the main CMakeLists.txt (in digikam root) there are a
> lot of libs defined, but in the end only a few of them are actually
> installed in /usr/lib. For example we define a libhaar, but I can't find it
> anywhere.

This is a very valid question.
Take CMakeLists.txt in the main project directory and digikam/CMakeList.txt in
the digikam/ subdir.
The former one defines a large number of "libs", like libcurves_SRCS,
libdimg_SRCS, libdimgloaders_SRCS etc. These are indeed not really libs, but
we just use this to package the huge list of source files in chunks. (They
were libs, static libs, with KDE3 and automake, so the lib... prefix is there
for historic reasons).

Now on to digikam/CMakeList.txt. This one defines the real binary objects that
we have: libdigikam, libdigikamdatabase and the digikam application binary
(the kioslaves and showfoto binaries are defined in their own
CMakeLists.txt). You see that we now use all the lib... defines from above to
group the source files into these binaries.
Now the layout here actually has a rationale:
libdigikam is the base library and contains all code shared between digikam,
showfoto, the ioslaves and the image plugins.
libdigikamdatabase obviously contains database code. It depends on libdigikam
and is used by digikam and the ioslaves, not by showfoto and the image
plugins.
Non-shared code is kept in the digikam binary.
There is no source file compiled twice in either of the binaries, with a few
small exceptions with digikam/showfoto.

Now to your DIGIKAM_EXPORT question: Any code that is contained in a library
and used from another binary must contain the DIGIKAM_EXPORT macro, or it
will result in "undefined reference" errors when linking.
So if code is contained in a library and does not carry the macro, it is not
intended to be used publicly (e.g. ImageInfoCache in libs/database/).
Code in an application binary, e.g. AlbumIconView, does not need the macro as
it will never be linked in a shared lib.

Marcel

>
> Maybe those questions are stupid, but I want to understand completely what
> we are doing here (in Cmake and in the code as well).
> For example my histogrambox widget: I just used copy and paste for it,
> because I didn't know what to do at this moment. So it has an EXPORT macro
> in front of the class and it also becomes installed in /usr/include, but I
> guess we don't need this widget the be accessed from outside of digiKam. So
> I could remove it from the INSTALL rule in the CMake file. But if I do so,
> do I have to remove the EXPORT macro as well or do I have to keep it.
>
>
> Andi
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

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

[Gilles Caulier-4]

Since digikam have been ported to windows, more export symbol macro have been added duing a lot of dll created during compilation process. Look export code from digiKam :

http://websvn.kde.org/trunk/extragear/graphics/digikam/digikam/digikam_export.h?revision=869774&view=markup

We can see an export macro for:

- digiKam core,
- database interface code,
- image editor,
- image filters (I supose it's shared by digiKam and showfoto)
- widgets (idem)

More comments must be set in this code to identify where we must use the right macro in digiKam code, especially for new implementations.

Gilles

2008/10/25 Marcel Wiesweg <[hidden email]>

> Gilles asked me to send this mail to the ML...
>
>
> Hi,
>
> I used to program in python all the time, so I'm still quite confused by
> the libs mechanism in C++.
>
> I understand that some of the .o files are packed into library files (to
> save space and make things easier) and some header files are stored
> in /usr/include/digikam to actually access those libs from the program the
> libs will be used in.
>
> But what are those DIGIKAM_EXPORT macros for? They seem to be in nearly
> every class although not every class seems to be exported into libs (or at
> least no header files exist in /usr/include/digikam).
>
> Do they signal gcc to pack those object files into libraries?
> I found out that in the main CMakeLists.txt (in digikam root) there are a
> lot of libs defined, but in the end only a few of them are actually
> installed in /usr/lib. For example we define a libhaar, but I can't find it
> anywhere.

This is a very valid question.
Take CMakeLists.txt in the main project directory and digikam/CMakeList.txt in
the digikam/ subdir.
The former one defines a large number of "libs", like libcurves_SRCS,
libdimg_SRCS, libdimgloaders_SRCS etc. These are indeed not really libs, but
we just use this to package the huge list of source files in chunks. (They
were libs, static libs, with KDE3 and automake, so the lib... prefix is there
for historic reasons).

Now on to digikam/CMakeList.txt. This one defines the real binary objects that
we have: libdigikam, libdigikamdatabase and the digikam application binary
(the kioslaves and showfoto binaries are defined in their own
CMakeLists.txt). You see that we now use all the lib... defines from above to
group the source files into these binaries.
Now the layout here actually has a rationale:
libdigikam is the base library and contains all code shared between digikam,
showfoto, the ioslaves and the image plugins.
libdigikamdatabase obviously contains database code. It depends on libdigikam
and is used by digikam and the ioslaves, not by showfoto and the image
plugins.
Non-shared code is kept in the digikam binary.
There is no source file compiled twice in either of the binaries, with a few
small exceptions with digikam/showfoto.

Now to your DIGIKAM_EXPORT question: Any code that is contained in a library
and used from another binary must contain the DIGIKAM_EXPORT macro, or it
will result in "undefined reference" errors when linking.
So if code is contained in a library and does not carry the macro, it is not
intended to be used publicly (e.g. ImageInfoCache in libs/database/).
Code in an application binary, e.g. AlbumIconView, does not need the macro as
it will never be linked in a shared lib.

Marcel

>
> Maybe those questions are stupid, but I want to understand completely what
> we are doing here (in Cmake and in the code as well).
> For example my histogrambox widget: I just used copy and paste for it,
> because I didn't know what to do at this moment. So it has an EXPORT macro
> in front of the class and it also becomes installed in /usr/include, but I
> guess we don't need this widget the be accessed from outside of digiKam. So
> I could remove it from the INSTALL rule in the CMake file. But if I do so,
> do I have to remove the EXPORT macro as well or do I have to keep it.
>
>
> Andi
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel


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

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

Thanks for all the explanation. I guess that helped a lot, if something is
still missing I'm asking again :D

Andi


On Saturday 25 October 2008 16:17:12 Marcel Wiesweg wrote:

> > Gilles asked me to send this mail to the ML...
> >
> >
> > Hi,
> >
> > I used to program in python all the time, so I'm still quite confused by
> > the libs mechanism in C++.
> >
> > I understand that some of the .o files are packed into library files (to
> > save space and make things easier) and some header files are stored
> > in /usr/include/digikam to actually access those libs from the program
> > the libs will be used in.
> >
> > But what are those DIGIKAM_EXPORT macros for? They seem to be in nearly
> > every class although not every class seems to be exported into libs (or
> > at least no header files exist in /usr/include/digikam).
> >
> > Do they signal gcc to pack those object files into libraries?
> > I found out that in the main CMakeLists.txt (in digikam root) there are a
> > lot of libs defined, but in the end only a few of them are actually
> > installed in /usr/lib. For example we define a libhaar, but I can't find
> > it anywhere.
>
> This is a very valid question.
> Take CMakeLists.txt in the main project directory and digikam/CMakeList.txt
> in the digikam/ subdir.
> The former one defines a large number of "libs", like libcurves_SRCS,
> libdimg_SRCS, libdimgloaders_SRCS etc. These are indeed not really libs,
> but we just use this to package the huge list of source files in chunks.
> (They were libs, static libs, with KDE3 and automake, so the lib... prefix
> is there for historic reasons).
>
> Now on to digikam/CMakeList.txt. This one defines the real binary objects
> that we have: libdigikam, libdigikamdatabase and the digikam application
> binary (the kioslaves and showfoto binaries are defined in their own
> CMakeLists.txt). You see that we now use all the lib... defines from above
> to group the source files into these binaries.
> Now the layout here actually has a rationale:
> libdigikam is the base library and contains all code shared between
> digikam, showfoto, the ioslaves and the image plugins.
> libdigikamdatabase obviously contains database code. It depends on
> libdigikam and is used by digikam and the ioslaves, not by showfoto and the
> image plugins.
> Non-shared code is kept in the digikam binary.
> There is no source file compiled twice in either of the binaries, with a
> few small exceptions with digikam/showfoto.
>
> Now to your DIGIKAM_EXPORT question: Any code that is contained in a
> library and used from another binary must contain the DIGIKAM_EXPORT macro,
> or it will result in "undefined reference" errors when linking.
> So if code is contained in a library and does not carry the macro, it is
> not intended to be used publicly (e.g. ImageInfoCache in libs/database/).
> Code in an application binary, e.g. AlbumIconView, does not need the macro
> as it will never be linked in a shared lib.
>
> Marcel
>
> > Maybe those questions are stupid, but I want to understand completely
> > what we are doing here (in Cmake and in the code as well).
> > For example my histogrambox widget: I just used copy and paste for it,
> > because I didn't know what to do at this moment. So it has an EXPORT
> > macro in front of the class and it also becomes installed in
> > /usr/include, but I guess we don't need this widget the be accessed from
> > outside of digiKam. So I could remove it from the INSTALL rule in the
> > CMake file. But if I do so, do I have to remove the EXPORT macro as well
> > or do I have to keep it.
> >
> >
> > Andi
> > _______________________________________________
> > Digikam-devel mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-devel
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

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