more comfortable approach for exporting dbus functions on windows

[Romain Pokrzywka]

Hmm, the quoting might have been wrong here, I'm not sure what parts were quotes and what parts were comments from 
Ralf...
Anyway, is there still a problem with that stuff ? AFAICS it's been committed a while ago already, and it works great 
for me. Maybe the autotools build still needs to be updated ?

Romain 
On Wednesday 17 March 2010 00:11:45 Ralf Habacker wrote:
> Ralf Habacker schrieb:
> > Ralf Habacker schrieb:
> >> Ralf Habacker schrieb:
> >> <snip>
> >>
> >>>>> The appended patch adds such support for the public dbus api
> >>>>> functions. The
> >>>>> internal symbols could be adressed in further patches.
> >>>>
> >>>> What change would need to be made to the internal symbols?
> >>>
> >>> to be clear - i used the term internal for dbus internal functions
> >>> indicated by the _dbus prefix, which are also exported from dbus-1
> >>> shared library.
> >>>
> >>> Symbols which are not exported do not need any decoration on
> >>> windows, because this is the default. if gcc on unix has a switch to
> >>> set the default symbol visibility to 'hidden', than there is also no
> >>> decoration required for this case. Otherwise the above mentioned
> >>> DBUS_NO_EXPORT could be used for this case.
> >>>
> >>> To export the dbus internal functions the following steps are required:
> >>>
> >>> 1. add DBUS_EXPORT to  _dbus_... function
> >>> 2. remove related symbolnames from xxx.def.in
> >>>
> >>> When all symbols are decorated the .def file creation and usage
> >>> could be removed in the autotools and cmake build system.
> >>
> >> Appended is a related patch - it removes def file usage for the cmake
> >> buildsystem too - please review
> >
> > are there still any problems with this patch ?
>
> While digging more into this stuff I recognized that there is also
> static dbus-internal library target, which contains all internal
> functions which are not in the dbus-1 library target.
> One reason for having internal functions in dbus-1 library is based on
> the fact that some dbus source files contains internal *AND* public
> functions like dbus-connection.c, but there are also files containing
> internal functions only.
>
> A related comment in the dbus/Makefile.am or cmake/dbus/CMakeLists.txt
> shows that in the beginning is was intended that internal symbols are
> also exported from the dbus-1 library.
>
> ### source code that goes in the installed client library
> ### AND is generic utility functionality used by the
> ### daemon or test programs (all symbols in here should
> ### be underscore-prefixed)
>
> but there is also the dbus-internal symbols which is also used for
> holding internal functions
>
> ### Internal library, used for the daemon, tools and tests, compiled
> statically.
>
> The dbus-internal library depends on dbus-1 library and both libraries
> are used to compile the dbus-daemon and helper tools
>
> |## don't export symbols that start with "_" (we use this
>
> ## convention for internal symbols)
> export_symbols = -export-symbols-regex "^[^_].*"
>
>
>
>
>
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus



-- 
Romain Pokrzywka | romain at kdab.com | Certified Qt Software Engineer & Trainer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100401/a5c1f2be/attachment.pgp>