Cyclic dependency in kabc
Hi, I'm getting this cool error: Building CXX object kabc/plugins/file/CMakeFiles/kabc_file.dir/resourcefileconfi g.obj resourcefileconfig.cpp Linking CXX shared library ..\..\..\bin\kabc_file.dll LINK : ..\..\..\bin\kabc_file.dll not found or not built by the last incremental link; performing full link Creating library ..\..\..\bin\kabc_file.lib and object ..\..\..\bin\kabc_file .exp Microsoft (R) Manifest Tool version 5.2.3790.2014 Copyright (c) Microsoft Corporation 2005. All rights reserved. Building CXX object kabc/plugins/file/CMakeFiles/kabc_file_plugin.dir/resourcefi leplugin.obj resourcefileplugin.cpp NMAKE : fatal error U1071: cycle in dependency tree for target 'bin\kabc_file.dl l' Stop. Any ideas? Paulo ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make install-exec
On Friday 28 April 2006 15:23, you wrote: Andras Mantia wrote: Previously we had an install-exec target for make which installed only libraries and applications (and modules of course). This is very handy if you have lot of data that does not change, but you have to install the executables often as it will take much less time (even if the timestamp is checked for modification). Is it possible to have something like this for cmake? I'd rather make install only installed what has changed. Unsermake had that feature. It already does that (as I understood starting from cmake 2.4.0), but it still prints out everything, even if it's not installed for real, and this is slow, for example in KDevelop, as it processes all the output. If it doesn't print what is not installed, it's fine for me as well. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org pgp00OyeYGYwx.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Need help with custom moc commands.
(Please CC to me as I am not a member of kde-buildsystem)
In Kopete (kdenetwork/kopete/protocols/jabber/libiris to be more precise), I
have some files where both header and implementation has the Q_OBJECT.
The Makefile.am used this trick:
s5b.lo: s5b.moc
CLEANFILES = s5b.moc
s5b.moc: $(srcdir)/s5b.cpp $(srcdir)/s5b.h
${MOC} $(srcdir)/s5b.h $@
${MOC} $(srcdir)/s5b.cpp $@
and here my attempt to reproduce it in CMake:
# BEGIN moc special case
# Those are special cases, both header and implementation contains a Q_OBJECT
macro
# What we do is generate a moc file for both header and implementation and
with CMake FILE command, create the final .moc
qt4_generate_moc( ${CMAKE_CURRENT_SOURCE_DIR}/iris/xmpp-core/securestream.h
${CMAKE_CURRENT_BINARY_DIR}/securestream_h.moc )
qt4_generate_moc( ${CMAKE_CURRENT_SOURCE_DIR}/iris/xmpp-core/securestream.cpp
${CMAKE_CURRENT_BINARY_DIR}/securestream_cpp.moc )
qt4_generate_moc( ${CMAKE_CURRENT_SOURCE_DIR}/iris/jabber/s5b.cpp
${CMAKE_CURRENT_BINARY_DIR}/s5b_cpp.moc )
qt4_generate_moc( ${CMAKE_CURRENT_SOURCE_DIR}/iris/jabber/s5b.h
${CMAKE_CURRENT_BINARY_DIR}/s5b_h.moc )
set(securestream_h_MOC)
set(securestream_cpp_MOC)
set(s5b_h_MOC)
set(s5b_cpp_MOC)
# Create securestream.moc
file(READ ${CMAKE_CURRENT_BINARY_DIR}/securestream_h.moc securestream_h_MOC)
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/securestream.moc ${securestream_h_MOC})
file(READ ${CMAKE_CURRENT_BINARY_DIR}/securestream_cpp.moc
securestream_cpp_MOC)
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/securestream.moc
${securestream_cpp_MOC})
# Create s5b.moc
file(READ ${CMAKE_CURRENT_BINARY_DIR}/s5b_h.moc s5b_h_MOC)
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/s5b.moc ${s5b_h_MOC})
file(READ ${CMAKE_CURRENT_BINARY_DIR}/s5b_cpp.moc s5b_cpp_MOC)
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/s5b.moc ${s5b_cpp_MOC})
# END moc special case
The resulting MOC with CMake doesn't compile, and I need a cleaner way to do
it.
Thank you
--
Michaël Larouche (Shock The Dark Mage)
KDE developer working on Kopete, Kamefu...on dial-up :P
--
Blog: http://mlarouche.blogspot.com/
MSN/Email: [EMAIL PROTECTED]
IRC: irc.freenode.org/DarkShock on #kopete,#solid,#kamefu,#plasma
Jabber: [EMAIL PROTECTED]
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make install-exec
On Friday, 28. April 2006 14:30, Andras Mantia wrote: It already does that (as I understood starting from cmake 2.4.0), but it still prints out everything, even if it's not installed for real, and this is slow, for example in KDevelop, as it processes all the output. If it doesn't print what is not installed, it's fine for me as well. Wouldn't it be better to fix kdevelop to not be that slow instead? -- Dirk//\ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make install-exec
On Friday 28 April 2006 16:07, Dirk Mueller wrote: On Friday, 28. April 2006 14:30, Andras Mantia wrote: It already does that (as I understood starting from cmake 2.4.0), but it still prints out everything, even if it's not installed for real, and this is slow, for example in KDevelop, as it processes all the output. If it doesn't print what is not installed, it's fine for me as well. Wouldn't it be better to fix kdevelop to not be that slow instead? It certainly needs a fix. ;-) But part of the slowness is QTextEdit (even in LogText mode) AFAIK. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org pgpTI1HSdZyjc.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Need help with custom moc commands.
On Friday 28 April 2006 14:46, Michaël Larouche wrote:
(Please CC to me as I am not a member of kde-buildsystem)
In Kopete (kdenetwork/kopete/protocols/jabber/libiris to be more precise),
I have some files where both header and implementation has the Q_OBJECT.
The Makefile.am used this trick:
s5b.lo: s5b.moc
CLEANFILES = s5b.moc
s5b.moc: $(srcdir)/s5b.cpp $(srcdir)/s5b.h
${MOC} $(srcdir)/s5b.h $@
${MOC} $(srcdir)/s5b.cpp $@
I don't think that this is a good idea.
Doesn't this give a cyclic dependency ?
s5b.moc depends on s5b.cpp, and s5b.cpp depends on s5b.moc because it includes
it ?
I'd suggest:
kde4_automoc( ${libiris_SRCS} )
qt4_wrap_cpp(libiris_SRCS s5b.cpp securestream.cpp )
This should just work. It will generate the moc stuff for the s5b.h and
securestream.h header which can be included and should generate extra moc
files for s5b.cpp and securestream.cpp, which will be compiled and linked as
separate files.
And it should avoid the cyclic dependency.
Bye
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: Please test: changes in how Qt4 is found
At 02:26 PM 4/28/2006, Thiago Macieira wrote: Kuba Ober wrote: Couldn't agree more, especially that I'm migrating some more build stuff at work to cmake. Cmake and Qt are the only dependencies for the product in question, I'd consider it weird at least to add pkg-config to the mix if a solution already exists and works. The weird thing is... every time this subject turns up (and it has, again and again), you get the Trolls saying: use pkg-config. That's the Trolltech-recommended way of finding Qt 4. Is that the Trolltech recommended way for windows and the Mac? If Trolltech required that pkg-config be installed before QT could be used on any platform, I would have no problem using it. But, that does not seem to be the case, unless I am missing something? So, what do the Trolls say should be done if pkg-config is not found? I am sure many Trolltech customers on windows do not have pkg-config and are happily using Qt, I am assuming the answer is use qmake, which is what we are doing. I suppose we could do some sort of hybrid approach. Something like this: 1. find qmake in the PATH 2. use pkg-config to find qmake 3. if 1 and 2 are the same qmake, then use the info from pkg-config 4. if pkg-config was not found, or it points to a different qmake than the one in the users PATH, then use qmake to setup the paths for the build. -Bill ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Please test: changes in how Qt4 is found
William A. Hoffman wrote: But we do recommend using pkg-config for finding Qt/X11. Not qmake. qmake is a separate program that doesn't have to be installed to use or develop with Qt. That is a surprise.I thought that qt used qmake as part of its own build process, and put qmake into the bin directory when qt was installed. It does. But Qt doesn't have to find Qt in order to build Qt. So we don't have to run pkg-config. The support is there, though. Most of our Windows-only users don't care about qmake. They use Microsoft's tools and that's it. At most, they use the Visual Studio integration and generate the project files with qmake, then stop using qmake. Cross platform (Windows/Linux projects) most likely depend on qmake to get things right. So, what about Windows/Linux users? They either use qmake themselves, or their own buildsystems (which means they don't use qmake). Cmake is the only buildsystem that depends on another buildsystem being installed (qmake) for it to work. What the FindQt4.cmake script is doing is akin to creating a configure.ac file and running autoconf configure. Use pkg-config to find qmake? Why? If pkg-config is found, ask it where QtCore is, what its CXXFLAGS are, what the rpath flags are, where moc, uic, etc. are. So, if someone builds qt, then puts that qt bin their PATH, but does not set the pkg-config environment variable, they will get the wrong qt if there are two on the system. Can pkg-config handle more than one build of QT? No, it won't be the wrong one. By definition, it will be the right one. Trolltech recommends using pkg-config, so what pkg-config finds is the correct one. And, yes, pkg-config can handle more than one prefix. Just set PKG_CONFIG_PATH to the one you want. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org thiago.macieira (AT) trolltech.com Trolltech AS GPG: 0x6EF45358 | Sandakerveien 116, E067 918B B660 DBD1 105C | NO-0402 966C 33F5 F005 6EF4 5358 | Oslo, Norway pgptAEfjKoGjW.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Please test: changes in how Qt4 is found
On Friday 28 April 2006 23:57, Thiago Macieira wrote: ... They either use qmake themselves, or their own buildsystems (which means they don't use qmake). Cmake is the only buildsystem that depends on another buildsystem being installed (qmake) for it to work. What the FindQt4.cmake script is doing is akin to creating a configure.ac file and running autoconf configure. cmake can: -use qmake -use pkg-config -use qmake and optionally use pkg-config -use pkg-config and optionally use qmake -use neither qmake nor pkg-config We can discuss this without end. No matter which option I'll choose there will be people arguing that just another option would be The Right One. As it is now it works for everybody on every platform without known problems. I think we have more important things to do than do discuss how to improve something which doesn't have any known problems. Bye 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
KDE/kdelibs
SVN commit 535237 by neundorf: -check where some of the results are used it seems there are quite a lot of checks which aren't used anywhere CCMAIL: kde-buildsystem@kde.org I moved the (seemingly) unused checks at the of the file, I guess they can be removed. Do we want modular configuration ? Then we should create a kjs-config.h, a kioslave-config.h, a kdecore-config.h and a kio-config.h I think. David, what do you think ? Alex M +79 -73ConfigureChecks.cmake ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
