Re: Merging of kdelibs_export.h and kdelibs_export_win.h
yesterday this change was made to kdelibs_export.h:
-#define KSPELL2_EXPORT KDE_EXPORT
+#define SONNET_EXPORT KDE_EXPORT
And this is still wrong!
-
kde4_add_library(sonnetcore SHARED ${sonnetbase_STAT_SRCS})
so it must be MAKE_SONNETCORE_LIB
once more recompiling whole kdelibs (but this time for win32 only) :(
Could someone explain the error to me, so that I don't mess up the build again.
Thanks,
Jacob
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
Christian Ehrlicher said the following, On 2007-01-23 22:34:
Jacob R Rideout schrieb:
yesterday this change was made to kdelibs_export.h:
-#define KSPELL2_EXPORT KDE_EXPORT
+#define SONNET_EXPORT KDE_EXPORT
And this is still wrong!
-
kde4_add_library(sonnetcore SHARED ${sonnetbase_STAT_SRCS})
so it must be MAKE_SONNETCORE_LIB
once more recompiling whole kdelibs (but this time for win32 only) :(
Could someone explain the error to me, so that I don't mess up the build
again.
I'll try. Don't we have a wiki page for this already? If not we should
create one.
Thanks for the explanation, I've also answered this question many times and
there's already article about this:
http://wiki.kde.org/tiki-index.php?page=KDElibs%2Fwin32+Porting+Guidelines#4_Header_files
BTW, We just need to move the pages out of the old wiki.
--
regards / pozdrawiam, Jaroslaw Staniek
Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
Kexi KOffice: http://www.kexi-project.org, http://www.koffice.org
KDE3 KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
On Monday 22 January 2007 15:46, David Faure wrote: 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. yesterday this change was made to kdelibs_export.h: -#define KSPELL2_EXPORT KDE_EXPORT +#define SONNET_EXPORT KDE_EXPORT today I tried to compile one thing in kdebase, and *every single file in kdebase* had to be recompiled, even though *nothing* in kdebase uses kspell2/sonnet. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_popupmenu.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konqhistorymanageradaptor.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/undomanageradaptor.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_settings.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/kfileivi.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_xmlguiclient.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_iconviewwidget.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/knewmenu.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_operations.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_dirpart.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_events.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_propsview.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_pixmapprovider.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_bgnddlg.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/kivdirectoryoverlay.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_historyentry.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_historymgr.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konqmimedata.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konqbookmarkmanager.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_filetip.o. Dependee /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_faviconmgr.o. I stand by what I said: we need to split it up ;) -- 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
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
On Tuesday 23 January 2007 18:36, David Faure wrote: On Monday 22 January 2007 15:46, David Faure wrote: 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. yesterday this change was made to kdelibs_export.h: -#define KSPELL2_EXPORT KDE_EXPORT +#define SONNET_EXPORT KDE_EXPORT today I tried to compile one thing in kdebase, and *every single file in kdebase* had to be recompiled, even though *nothing* in kdebase uses kspell2/sonnet. ... /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_faviconmgr.o. I stand by what I said: we need to split it up ;) You have my full support. Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org- http://www.kde.org alex AT neundorf.net - http://www.neundorf.net ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
David Faure schrieb:
On Monday 22 January 2007 15:46, David Faure wrote:
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.
yesterday this change was made to kdelibs_export.h:
-#define KSPELL2_EXPORT KDE_EXPORT
+#define SONNET_EXPORT KDE_EXPORT
And this is still wrong!
-
kde4_add_library(sonnetcore SHARED ${sonnetbase_STAT_SRCS})
so it must be MAKE_SONNETCORE_LIB
once more recompiling whole kdelibs (but this time for win32 only) :(
Christian
signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
David Faure schrieb: On Tuesday 23 January 2007 19:16, Christian Ehrlicher wrote: Alexander Neundorf schrieb: On Tuesday 23 January 2007 18:36, David Faure wrote: On Monday 22 January 2007 15:46, David Faure wrote: 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. yesterday this change was made to kdelibs_export.h: -#define KSPELL2_EXPORT KDE_EXPORT +#define SONNET_EXPORT KDE_EXPORT today I tried to compile one thing in kdebase, and *every single file in kdebase* had to be recompiled, even though *nothing* in kdebase uses kspell2/sonnet. ... /d/kde/inst/kde4/include/kdelibs_export.h is newer than depender libkonq/CMakeFiles/konq.dir/konq_faviconmgr.o. I stand by what I said: we need to split it up ;) You have my full support. Can't this somehow autocreated by cmake for every subdir of kdelibs? Can't you collect them all in kde4_add_library()? I autocreate foo_export.h files with my kdesdk script, but I don't think we can go to the next step of full automation; every subdir doesn't define its own lib. That's clear - therefore I wanted to 'save' them inside kde4_add_library() and create the header with another cmake macro. Don't know if this is possible... Plus in some cases we might want an extra export macro that is only set when unit tests are enabled (we do that in koffice, maybe one day we need that in kdelibs too). Then the new cmake command should look for kde_foo_export.h.cmake and add the definitions instead creating an own header. Just an idea :) Christian btw: just found out that we need some more sonnet_export macros... :( signature.asc Description: OpenPGP digital signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
On Tuesday 23 January 2007 19:56, Alexander Neundorf wrote: On Tuesday 23 January 2007 19:52, Christian Ehrlicher wrote: ... Then the new cmake command should look for kde_foo_export.h.cmake and add the definitions instead creating an own header. This would then be done everytime cmake runs. Do we want this ? Isn't that just like moc generation? (create file if it doesn't exist yet) -- 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
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
Christian Ehrlicher wrote:
kde4_add_library(sonnetcore SHARED ${sonnetbase_STAT_SRCS})
so it must be MAKE_SONNETCORE_LIB
I am changing that symbol to sonnetcore_EXPORTS instead. I asked here and
no one opposed...
I had all of kdelibs_export.h done... But if we're going to split -- and
now I think we should -- then we don't have to care about which symbol it
is.
KDE4_ADD_LIBRARY knows which symbol it defines. It's a very, very simple
file to generate and doesn't even need include guards (the macro name is
its own include guard):
#include kdemacros.h
#ifndef LIBNAME_EXPORT
# ifdef libname_EXPORTS
# define LIBNAME_EXPORT KDE_EXPORT
# else
# define LIBNAME_EXPORT KDE_IMPORT
# endif
#endif
I don't have the expertise to add this. Alex?
once more recompiling whole kdelibs (but this time for win32 only) :(
So let's not have the _win.h file anymore, like I proposed.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
pgpiYbEGLJOja.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
Thiago Macieira schrieb:
Christian Ehrlicher wrote:
kde4_add_library(sonnetcore SHARED ${sonnetbase_STAT_SRCS})
so it must be MAKE_SONNETCORE_LIB
I am changing that symbol to sonnetcore_EXPORTS instead. I asked here and
no one opposed...
How you name the export is not the problem - you must just take care to
use the correct MAKE_foo_LIB in kdelibs_export_win.h. It does not affect
linux in any way.
I could not recompile kdelibs for some days, so I did not recognize that
sonnet exports were messed up on win32. Since sonnetcore and sonnetui
are created, we also have MAKE_SONNETCORE_LIB and MAKE_SONNETUI_LIB...
And there is one more problem inside sonnet - some sources for
sonnetcore are also used for sonnetui (looks like an old convienence lib
for me) which breaks compilation on win32 too.
I'll check all needed changes as soon as I've successfully build kdelibs.
Christian
signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
Christian Ehrlicher wrote: And there is one more problem inside sonnet - some sources for sonnetcore are also used for sonnetui (looks like an old convienence lib for me) which breaks compilation on win32 too. I'm going to make the build on 32-bit break on Unix too, if you do that mistake. I can't apply the same trick (#define KDE_IMPORT to empty) on 64-bit. I'll check all needed changes as soon as I've successfully build kdelibs. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpFdN6PLBSBy.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
Jacob R Rideout schrieb:
yesterday this change was made to kdelibs_export.h:
-#define KSPELL2_EXPORT KDE_EXPORT
+#define SONNET_EXPORT KDE_EXPORT
And this is still wrong!
-
kde4_add_library(sonnetcore SHARED ${sonnetbase_STAT_SRCS})
so it must be MAKE_SONNETCORE_LIB
once more recompiling whole kdelibs (but this time for win32 only) :(
Could someone explain the error to me, so that I don't mess up the build
again.
I'll try. Don't we have a wiki page for this already? If not we should
create one.
On Windows you need to export your functions in a shared lib to allow
access to those functions from outside. At this point it's the same like
gcc's visibility support. The main difference is, that if you want to
use such an exported function, you need to decorate them in another way.
This means that you have to define FOO_EXPORT depending on what you want do:
#ifdef MAKE_SONNETCORE_LIB
// here we build the lib
# define SONNETCORE_EXPORT KDE_EXPORT
#else
// here we use the lib
# define SONNETCORE_EXPORT KDE_IMPORT
#endif
MAKE_FOO_LIB is automatically defined when you use kde4_add_library(foo
...).
Please ask if there is something unclear - I'm not very good in
explaining things in an understandable way :)
Christian
signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
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
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
Christian Ehrlicher wrote: Thiago Macieira schrieb: I've noticed that CMake defines a macro called targetname_EXPORTS for each module that is being built. Would the Win32 guys oppose if I merged the two export headers into one and used that macro instead? Afaik the _win.h was just introduced by Jaroslaw to reduce unneded recompiling on linux when he changed a define for windows. So it can be merged for kdelibs4 I'm also reintroducing the #include QtCore/qglobal.h for C compilations as well. It's supposed to work and any bugs should be reported with urgency to Trolltech. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpOsu2YaR5Tk.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Merging of kdelibs_export.h and kdelibs_export_win.h
Thiago Macieira wrote: I didn't know we had such a script. Patch is attached. 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. Don't apply the patch yet. Please wait for kdemacros.h to be changed. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 pgpH60OTJ06Ot.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
