[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: more comfortable approach for exporting dbus functions on windows
From:       Romain Pokrzywka <romain () kdab ! com>
Date:       2010-04-01 11:49:21
Message-ID: 201004011349.25414.romain () kdab ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus



-- 
Romain Pokrzywka | romain@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


["signature.asc" (application/pgp-signature)]

_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus


[prev in list] [next in list] [prev in thread] [next in thread]