On Saturday 20 January 2007 12:21, Thiago Macieira wrote: > David Faure wrote: > >Speaking of unneeded recompilations, can I suggest that we also split up > > the export.h file into one-file-per-lib, like I did in koffice last > > week? It also makes things more modular and easier to move when needed. > > That makes a LOT of extra files to install in kdelibs. I am not sure we > gain a big advantage by doing that.
I think modularity is always a huge advantage. Moving kmail from kdenetwork to kdepim (yes, always the same example, a traumatic experience ;) would have been so much easier if it came with its own configure checks and its own file with export macros etc. Nothing should be module-wide. Stuff moves. Stuff is partially checked out. etc. > I didn't know we had such a script. Patch is attached. Thanks. > I don't think kdemacros.h has to be generated anymore. A static file will > do just fine. We can use Q_DECL_IMPORT and Q_DECL_EXPORT -- all I have to > do is convince the Trolls to move their definition to outside the ifdef > __cplusplus part. I thought we didn't want to use those macros because Qt's definition of "a compiler that supports hidden visibility" and KDE's definition varied a little bit. At least they did in qt3/kde3 times because kde was hitting bugs in some versions of gcc where hidden-visibility was however implemented good enough for qt's needs (which are less than kde's needs). Dirk probably has more concrete details about this, but I think it does make sense to keep this distinction since after all we have our own configure check for whether gcc supports hidden-visibility, so in case there's any mismatch between what qt detected and what kde detected, things might not compile. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
