kdelibs/kdecore

[Jarosław Staniek]

 Zack Rusin wrote:
 
 > On Wednesday 08 September 2004 20:34, David Faure wrote:
 >> Modularity? The goals of kdemacros.h and kdelibs.h are pretty
 >> different. And basically, a normal unix KDE developer needs to care
 >> about kdemacros.h but not about kdelibs.h
 > 
 > Both contain macros, don't they? :)
 > 
 >> > Why do we need _KDE_EXPORT_ and
 >> > KDE_EXPORT which do essentially the same thing but one for msvc and
 >> > the other gcc?
 >>
 >> They are not the same thing at all.
 >> KDE_EXPORT is playing with gcc's hidden/visible attributes, to create
 >> smaller binaries with less symbols; it's pretty much at the method
 >> level, and is optional (just an optimization). It has KDE_NO_EXPORT
 >> for the opposite meaning.
 >>
 >> The kdelibs.h macros (like _KDE_EXPORT_) are used at the class level,
 >> and are necessary for compiling on msvc. See Qt's own FOO_EXPORT
 >> macros too. You need a macro whose meaning changes depending on
 >> whether you're using a class from the outside or implementing the
 >> class... so this is all quite different. This one really only makes
 >> sense at the class (and function) level; not method.
 > 
 > Nope, that's not true. They're exactly the same thing, for exactly the
 > same purpose. The difference is that GCC folks messed up on having the
 > visibility class wide and that is covered in
 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9283 and in
 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15000 . Considering how
 > scare the usage of those export statemants is and that gcc 3.5 will
 > have proper support for it, I think we should simply boost the check in
 > macros to 3.5 and encapsulate the msvc code with it. Like I said they
 > serve exactly the same purpose.
 > 
 > This is especially important because it will allow to compile kdelibs
 > with -fvisibility=hidden once it's 3.5 becomes widely used.
 > 
 >> > And finally why do we need export define for almost every
 >> > single lib we have in kdelibs?
 >>
 >> You'd prefer a kdelibs_internal.h with all the toggling (for
 >> compiling each lib), and a public kdelibs.h with only the "used from
 >> outside" (_KDE_IMPORT) meaning of the macros? I'm not sure how that
 >> helps (more duplication, that's all). The same number of macros would
 >> still be needed.
 > 
 > Well, I think everything is better than kdelibs.h header name. Even
 > mydadisstrongerthenyou.h would be more descriptive as to its purpose :)
 
 Zack,
 Having used gcc probably for ages, you seem do not remember/care too much 
 issues with linking libraries for win32 world, where symbols are hidden by 
 default (not visible by default as e.g. on unix). See this thread:
 
 http://lists.kde.org/?l=kde-core-devel&m=105154800130902&w=2
 
 Why kdelibs.h? Because there is a simple rule:
 
 Such a file should be added for *EVERY kde cvs module*. And here we've got 
 "kdelibs" module. For example there will probably be added koffice.h as well 
 for "koffice" module. 
 
 The alternative (for KDElibs) was something like in Makefile.global we've 
used in Kexi:
 
 http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/koffice/kexi/Makefile.global?rev=1.15&content-type=text/plain
 
 ie. : command line options. Most people do not want to see additional few 
 lines of "-DFOOBAR_EXPORT=" during compilation. And for similar reason people 
 didn't want to see "-include everymodule.h" appended to the command line. 
 Also this makes little more hard to maintain Makefile.am files.
 
 And last, but not least: "kdelibs.h" is included in a *lazy* way, what means 
 it is only included if no other header from kdelibs is included in a given 
 header.
 
 For more information on rules for **_EXPORT macros (and many more), see:
 
 http://wiki.kde.org/tiki-index.php?page=KDElibs%2Fwin32+Porting+Guidelines
 
 -- 
 regards / pozdrawiam,
   Jaroslaw Staniek / OpenOffice Polska
   Kexi Project: http://www.kexi-project.org, http://koffice.kde.org/kexi
   QT-KDE Wrapper Project: http://iidea.pl/~js/qkw