Re: kde4_automoc change (need help)
On Wednesday 10 May 2006 15:00, David Faure wrote:
> I want to implement "Q_OBJECT in .cpp file and no .h file at all, and .cpp
> includes .moc" support in kde4_automoc, for unit tests. Would be much more
> convenient than having to write a .h file for each, and by having the "no
> header file" condition there we avoid grepping both .h and .cpp for
> Q_OBJECT in all cases, which might slow things down.
How about using Qt4_WRAP_CPP() ?
Usage:
set(mySrcs foo.cpp widget.cpp main.cpp)
qt4_wrap_cpp(mySrcs widget.cpp) # <- all files which have to be moc'ed.
... would also not make automoc yet slower.
>
> But my current implementation doesn't work - no moc file, and the binary is
> being linked without any source file as input... I'm stumped.
>
> --- KDE4Macros.cmake(revision 538918)
> +++ KDE4Macros.cmake(working copy)
> @@ -240,6 +240,19 @@
> get_filename_component(_basename ${_current_MOC} NAME_WE)
> # set(_header ${CMAKE_CURRENT_SOURCE_DIR}/${_basename}.h)
> set(_header ${_abs_PATH}/${_basename}.h)
> +
> + # Check if the header exists
> + if (NOT EXISTS ${_header})
> + # Otherwise check if the cpp file has Q_OBJECT
> + string(REGEX MATCH "Q_OBJECT" _match "${_contents}")
> + if (_match)
Isn't it matched ?
Maybe ".*Q_OBJECT.*" should work ?
> + # Yes -> moc the cpp file, not the non-existing
> header file. + set(_header ${_abs_FILE})
> + else (_match)
> + message(FATAL_ERROR "${_abs_FILE} includes
> ${_moc_INCS} but there's no ${_header} file and no Q_OBJECT in ${_abs_FILE}
> either") + endif (_match)
> + endif (NOT EXISTS ${_header})
> +
> set(_moc${CMAKE_CURRENT_BINARY_DIR}/${_current_MOC})
>#set(_moc${_abs_PATH}/${_current_MOC})
> add_custom_command(OUTPUT ${_moc}
> COMMAND ${QT_MOC_EXECUTABLE}
> ARGS ${_moc_INCS} ${_header} -o ${_moc}
> MAIN_DEPENDENCY ${_header}
>)
>
> The testcase:
> set(kovariabletest_SRCS kovariabletest.cpp)
> kde4_automoc(${kovariabletest_SRCS})
> kde4_add_executable(kovariabletest RUN_UNINSTALLED ${kovariabletest_SRCS})
> target_link_libraries(kovariabletest kotext ${QT_QTTEST_LIBRARY})
>
> with kovariabletest.cpp defining a QObject-derived class, with Q_OBJECT
> macro and #include "kovariabletest.moc"
>
> What happens:
> Linking CXX executable kovariabletest
> /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../lib64/crt1.o: In function
> `_start':../sysdeps/x86_64/elf/start.S:109: undefined reference to `main'
> Indeed in CMakeFiles/kovariabletest.dir/build.make, kovariabletest_OBJECTS
> is empty! How could this happen, given that I checked and
> ${kovariabletest_SRCS} is definitely not empty just before the call to
> kde4_add_executable...
Hmm, strange.
I'll have a closer look later.
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: KDE/kdelibs/cmake/modules
On Thursday 04 May 2006 23:52, Tanner Lovelace wrote: > On 5/4/06, David Faure <[EMAIL PROTECTED]> wrote: > > SVN commit 537476 by dfaure: > > > > Factorize the version-number parsing and checking code into a separate > > macro. Already used by the gpgme version check in kdepim. > > FindQt4 has similar code, but since it's a fork of a CMake module I'm not > > sure if I should modify it > > AFAIK, CMake was planning on replacing their version of FindQt4.cmake > with the one in KDE (please correct if wrong), so it might make sense > go ahead and modify it. As long as MacroEnsureVersion.cmake is > generic enough to go into cmake and they agree to take it I would > think it would be ok. > > I've also got some changes (for OS X) that need to go into > FindQt4.cmake now that we require cmake 2.4.x. Can you commit them to FindQt4.cmake kdelibs trunk ? 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: msvc: qHash
On Thursday 11 May 2006 19:23, Peter Kümmel wrote: > Christian Ehrlicher wrote: > > David Faure schrieb: > >> On Thursday 11 May 2006 18:36, Peter Kümmel wrote: > >>> David Faure wrote: > I'm confused. This file doesn't use QHash/QSet at all, so why is a QHash > implementation needed? > Is it due to some other file hashing KSortableItems? > > >>> Yes, compiling stops there because it couldn't find a qHash function with > >>> the correct argument. > >> Where's "there"? I am quite confused as to why any code would try to hash > >> KSortableItem or KSortableList. > >> > >> Do you mean that even kdecore/tests/ksortablelisttest doesn't compile? > >> > > http://marc.theaimsgroup.com/?l=kde-core-devel&m=113126965312032&w=2 > > > > Christian > > > > Oh, I see. But I think in this case it is better to use the > template version than to define multiple qHash functions. > > And how does GCC handle such code? gcc doesn't instanciate QList::toSet unless the code is calling it. -- 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: msvc: qHash
Christian Ehrlicher wrote: > David Faure schrieb: >> On Thursday 11 May 2006 18:36, Peter Kümmel wrote: >>> David Faure wrote: I'm confused. This file doesn't use QHash/QSet at all, so why is a QHash implementation needed? Is it due to some other file hashing KSortableItems? >>> Yes, compiling stops there because it couldn't find a qHash function with >>> the correct argument. >> Where's "there"? I am quite confused as to why any code would try to hash >> KSortableItem or KSortableList. >> >> Do you mean that even kdecore/tests/ksortablelisttest doesn't compile? >> > http://marc.theaimsgroup.com/?l=kde-core-devel&m=113126965312032&w=2 > > Christian > Oh, I see. But I think in this case it is better to use the template version than to define multiple qHash functions. And how does GCC handle such code? Peter ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: msvc: qHash
David Faure wrote: > On Thursday 11 May 2006 18:36, Peter Kümmel wrote: >> David Faure wrote: >>> I'm confused. This file doesn't use QHash/QSet at all, so why is a QHash >>> implementation needed? >>> Is it due to some other file hashing KSortableItems? >>> >> Yes, compiling stops there because it couldn't find a qHash function with >> the correct argument. > > Where's "there"? I am quite confused as to why any code would try to hash > KSortableItem or KSortableList. > > Do you mean that even kdecore/tests/ksortablelisttest doesn't compile? > When disabling the hack this happens: Building CXX object kdeui/CMakeFiles/kdeui.dir/keditlistbox.obj keditlistbox.cpp c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(729) : error C2665: 'qHash' : none of the 16 overloads could convert all the argument types c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/kernel/qabstractitemmodel.h(316): could be 'uint qHash(const QModelIndex &)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(37): or 'uint qHash(char)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(38): or 'uint qHash(uchar)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(39): or 'uint qHash(signed char)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(40): or 'uint qHash(ushort)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(41): or 'uint qHash(short)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(42): or 'uint qHash(uint)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(43): or 'uint qHash(int)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(44): or 'uint qHash(ulong)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(52): or 'uint qHash(long)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(53): or 'uint qHash(quint64)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(61): or 'uint qHash(qint64)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(62): or 'uint qHash(QChar)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(63): or 'uint qHash(const QByteArray &)' c:\sandbox\qt4\qt4\include\qtcore\../../src/corelib/tools/qhash.h(64): or 'uint qHash(const QString &)' c:\sandbox\qt4\qt4\include\qtgui\../../src/gui/itemviews/qitemselectionmodel.h(160): or 'uint qHash(const QItemSelec tionRange &)' while trying to match the argument list '(const KSortableItem)' with [ T=QString, Key=int ] ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: msvc: qHash
On Thursday 11 May 2006 18:52, David Faure wrote: > On Thursday 11 May 2006 18:36, Peter Kümmel wrote: > > David Faure wrote: > > > > > > I'm confused. This file doesn't use QHash/QSet at all, so why is a QHash > > > implementation needed? > > > Is it due to some other file hashing KSortableItems? > > > > > > > Yes, compiling stops there because it couldn't find a qHash function with > > the correct argument. > > Where's "there"? I am quite confused as to why any code would try to hash > KSortableItem or KSortableList. Ah I see the answer on kde-core-devel. Because of the stupid QList::toSet method. Ah well. Ok for a hack then. But casting a pointer to an int will break on Windows 64 bit, so better use "Q_ASSERT(0); return 0;" there. I honestly see no reason at all why someone would use a set or hash in combination with KSortableItem. -- 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: msvc: qHash
David Faure schrieb: > On Thursday 11 May 2006 18:36, Peter Kümmel wrote: >> David Faure wrote: >>> I'm confused. This file doesn't use QHash/QSet at all, so why is a QHash >>> implementation needed? >>> Is it due to some other file hashing KSortableItems? >>> >> Yes, compiling stops there because it couldn't find a qHash function with >> the correct argument. > > Where's "there"? I am quite confused as to why any code would try to hash > KSortableItem or KSortableList. > > Do you mean that even kdecore/tests/ksortablelisttest doesn't compile? > http://marc.theaimsgroup.com/?l=kde-core-devel&m=113126965312032&w=2 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/khtml
SVN commit 539758 by dfaure:
The FindJPEG provided by cmake doesn't obey the REQUIRED flag - it doesn't
error out when libjpeg isn't found.
Should this be fixed in cmake's FindJPEG.cmake?
CCMAIL: kde-buildsystem@kde.org
M +5 -0 CMakeLists.txt
--- trunk/KDE/kdelibs/khtml/CMakeLists.txt #539757:539758
@@ -6,6 +6,11 @@
find_package(GIF REQUIRED)
find_package(PNG REQUIRED)
+# not done by cmake's FindJPEG.cmake:
+if (NOT JPEG_FOUND)
+ message(FATAL_ERROR "JPEG library not found, required by KHTML - please
install libjpeg")
+endif (NOT JPEG_FOUND)
+
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE4_ENABLE_EXCEPTIONS}")
# khtml/dom/Makefile.am: khtmldom
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
KDE/kdelibs/cmake/modules
SVN commit 539757 by neundorf: -enhanced syntax for KDE4_ADD_EXECUTABLE and KDE4_ADD_KDEINIT_EXECUTABLE: KDE4_ADD_EXECUTABLE(name [NOGUI] [RUN_UNINSTALLED] srcs...) KDE4_ADD_KDEINIT_EXECUTABLE(name [NOGUI] [RUN_UNINSTALLED] srcs...) -> NOGUI and RUN_UNINSTALLED can now be used independently together. This also means that RUN_UNINSTALLED no longer automatically means NOGUI. -build libs and plugins with empty RPATH, so they don't have to be relinked during make install Alex CCMAIL: kde-buildsystem@kde.org M +15 -15FindKDE4Internal.cmake M +2 -0 FindQt4.cmake M +89 -29KDE4Macros.cmake ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: msvc: qHash
On Thursday 11 May 2006 18:36, Peter Kümmel wrote: > David Faure wrote: > > > > I'm confused. This file doesn't use QHash/QSet at all, so why is a QHash > > implementation needed? > > Is it due to some other file hashing KSortableItems? > > > > Yes, compiling stops there because it couldn't find a qHash function with the > correct argument. Where's "there"? I am quite confused as to why any code would try to hash KSortableItem or KSortableList. Do you mean that even kdecore/tests/ksortablelisttest doesn't 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: msvc: qHash
David Faure wrote: > > I'm confused. This file doesn't use QHash/QSet at all, so why is a QHash > implementation needed? > Is it due to some other file hashing KSortableItems? > Yes, compiling stops there because it couldn't find a qHash function with the correct argument. > In fact I'm wondering if we really need KSortable[Value]List with Qt4, when > it's easy > to just pass a function to > qSort(foo.begin(),foo.end(),mySortingFunctionHere) > or to use a map, for something closer to the usage of KSortableValueList. > > I'll start with porting the code I maintain away from KSortableValueList ;) > ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: cmake rule: processing .uic files
William A. Hoffman wrote:
>
>
> Are you talking about the location of cmake, or the install path for kdelibs?
>
> -Bill
>
The install path of cmake ("cmake 2.4", which is the default value).
Maybe it is better (at least for win/kdelibs users) to use a default
value without spaces.
Peter
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: msvc: qHash
> On Thursday 11 May 2006 00:00, David Faure wrote: > > In fact I'm wondering if we really need KSortable[Value]List with Qt4, > when it's easy > > to just pass a function to > qSort(foo.begin(),foo.end(),mySortingFunctionHere) > > or to use a map, for something closer to the usage of > KSortableValueList. > > I'll start with porting the code I maintain away from KSortableValueList > ;) > > OK I removed its use in libkonq, but the use of KSortableValueList in > KCompletion (kdeui) > is a bit over my head so I'd rather not touch it. So KSortableValueList > stays for now > (although the "Value" should be removed from its name...). > > But I'm back to the original question: why is qHash needed at all? > There once was a similar discussion in December - and KDE_DUMMY_QHASH_FUNCTION(C) (kdemacros.h.cmake) was born... Christian -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
RE: cmake rule: processing .uic files
> -Original Message-
> From: William A. Hoffman [mailto:[EMAIL PROTECTED]
> Sent: quinta-feira, 11 de Maio de 2006 13:38
> To: kde-buildsystem@kde.org; kde-buildsystem@kde.org
> Subject: Re: cmake rule: processing .uic files
>
> At 03:37 PM 5/10/2006, Peter Kümmel wrote:
> >Peter Kümmel wrote:
> >> The processing of .uic files does not work
> >> any more with nmake under win2k.
> >>
> >> e.g:
> >>
> >> set( kdeui_UI
> >>kspellui.ui
> >>kkeydialog.ui
> >>kshortcutdialog_simple.ui
> >>kshortcutdialog_advanced.ui
> >>)
> >>
> >> kde4_add_ui_files(kdeui_LIB_SRCS ${kdeui_UI} )
> >>
> >>
> >> does not generate kshortcutdialog_simple.h
> >>
> >>
> >> Before 2 months there were no problems, so something has
> >> broken it.
> >>
> >> Peter
> >
> >cmake install path without spaces helps!
>
>
> Are you talking about the location of cmake, or the install path for
> kdelibs?
If it is the install path for kdelibs I commited a fix yesterday.
Regarding the location of cmake I have it on "Program Files" and it doesn't
give me any trouble.
Paulo
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Fwd: How to build static libraries with cmake (and more)? (was: Re: Testing internal classes)
Hi, moving the discussion from kde-core-devel to the more appropriate place, I guess :) For those who did not follow there: We have been discussing the problem that internal classes are not visible outside of libraries if using visibility masks, so linking the libraries to tests for those classes does not work anymore. Am Donnerstag, 11. Mai 2006 00:14, schrieb David Faure: > On Wednesday 10 May 2006 21:44, Thiago Macieira wrote: > > Maybe our debug build could do like that: no symbol hiding. > > And then all the developers using debug builds would keep making > visibility-related mistakes. Not a good idea IMHO. Hm, true. This also applies to the troll solution, Simon told us about, using Q_INTERNAL_EXPORT macro and doing special test builds. And it hurts testing, if one has to do an extra step with switching between internal and external builds. :/ > I think we should just use convenience libs (but I'm not sure if cmake > supports that since we didn't need this up to now) or to link the .o files > into the test programs. I agree with Frans here, convenience libs are more convenient, not only by name ;) and that's needed for testing. Linking the .o files manually might make sense if the tests should also test for dependencies. But don't most people check for this already in the normal build? At least I do by separating coupled code in separate (convenience) libraries and linking those explicitly to needed libs, checking for unsolved symbols... oh, I think I have done, but I do not find any examples right now... thinking and working in separate worlds, again? :| Can one check static libraries for unresolved symbols, and is this portable? So given the restrictions Thiago teached me I see two solutions, perhaps both are needed/usable: a) Building a separate static library next to the dynamic one b) Buidling a separate dynamic library with visibility masking turned off, postfixed *_test or something, only used by tests Solution a) would be the convenient case for linking in the .o files, for basic classes with no further dependencies on other libs or for controlling the other linked libraries in the test build. Solution b) would be even more convenient for those tests where one doesn't (want to) care about dependencies on other libs for each test, but define them in one place (linking of the separate dynamic lib) and be done. Alex, William, any other cmake guru, please: (How) could we build static libraries? (How) could we build separate libraries with some build flag (visibility here) turned off? (How) could/should we link to uninstalled libraries (very much appreciated)? What false assumptions did I make again? <:) Are there any plans to "make test/check" trigger a test build like with auto*? Does this all make sense? Regards Friedrich pgpn1RdGtyY4O.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: msvc: qHash
On Thursday 11 May 2006 00:00, David Faure wrote: > In fact I'm wondering if we really need KSortable[Value]List with Qt4, when > it's easy > to just pass a function to > qSort(foo.begin(),foo.end(),mySortingFunctionHere) > or to use a map, for something closer to the usage of KSortableValueList. > I'll start with porting the code I maintain away from KSortableValueList ;) OK I removed its use in libkonq, but the use of KSortableValueList in KCompletion (kdeui) is a bit over my head so I'd rather not touch it. So KSortableValueList stays for now (although the "Value" should be removed from its name...). But I'm back to the original question: why is qHash needed at all? -- 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: cmake rule: processing .uic files
At 03:37 PM 5/10/2006, Peter Kümmel wrote:
>Peter Kümmel wrote:
>> The processing of .uic files does not work
>> any more with nmake under win2k.
>>
>> e.g:
>>
>> set( kdeui_UI
>>kspellui.ui
>>kkeydialog.ui
>>kshortcutdialog_simple.ui
>>kshortcutdialog_advanced.ui
>>)
>>
>> kde4_add_ui_files(kdeui_LIB_SRCS ${kdeui_UI} )
>>
>>
>> does not generate kshortcutdialog_simple.h
>>
>>
>> Before 2 months there were no problems, so something has
>> broken it.
>>
>> Peter
>
>cmake install path without spaces helps!
Are you talking about the location of cmake, or the install path for kdelibs?
-Bill
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
