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
KDE/kdelibs/cmake/modules
SVN commit 626619 by thiago:
Add macro KDE4_ADD_TEST for unit test usage. This way, if you have
CMake 2.4.4 or later, you don't need to turn on KDE4_BUILD_TESTS to be
allowed to build tests: just cd into the tests dir and
make targetname.
PS: it's time we bumped the minimum version requirement for CMake...
CCMAIL:kde-buildsystem@kde.org
M +33 -0 KDE4Macros.cmake
--- trunk/KDE/kdelibs/cmake/modules/KDE4Macros.cmake #626618:626619
@@ -663,6 +663,39 @@
endmacro (KDE4_ADD_KDEINIT_EXECUTABLE)
+macro (KDE4_ADD_TEST _target_NAME)
+
+ MATH(EXPR cmake_version ${CMAKE_MAJOR_VERSION} * 1 +
${CMAKE_MINOR_VERSION} * 100 + ${CMAKE_PATCH_VERSION})
+
+ set(_add_executable_param)
+ set(_go)
+ if (KDE4_BUILD_TESTS)
+ set(_go TRUE)
+ else (KDE4_BUILD_TESTS)
+ if (cmake_version GREATER 20403)
+ set(_go TRUE)
+ set(_add_executable_param EXCLUDE_FROM_ALL)
+ endif (cmake_version GREATER 20403)
+ endif (KDE4_BUILD_TESTS)
+
+ if (_go)
+ kde4_get_automoc_files(_automoc_FILES ${ARGN})
+
+ add_executable(${_target_NAME} ${_add_executable_param} ${ARGN}
${_automoc_FILES})
+
+ set_target_properties(${_target_NAME} PROPERTIES
+EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}
+DEFINITIONS
-DKDESRCDIR=\\${CMAKE_CURRENT_SOURCE_DIR}\\
+SKIP_BUILD_RPATH FALSE
+BUILD_WITH_INSTALL_RPATH FALSE)
+
+ if (WIN32)
+ target_link_libraries(${_target_NAME} ${QT_QTMAIN_LIBRARY})
+ endif (WIN32)
+
+endif (_go)
+endmacro (KDE4_ADD_TEST)
+
macro (KDE4_ADD_EXECUTABLE _target_NAME)
kde4_check_executable_params( _SRCS _nogui _uninst ${ARGN})
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
