Re: Problem using Vc with CMake 3.0 and kf5
On Wednesday 27 May 2015 11:19:08 Boudewijn Rempt wrote:
On Wed, 27 May 2015, Matthias Kretz wrote:
I have to admit I didn't know about this change in cmake. I think it's the
right direction, though. I just started to read the relevant cmake
documentation and then I'll see whether I can figure something out to make
the macro work for target-based compiler flags.
I tried to build our stuff with Vc 0.7 but the VcMacros.cmake from Vc
master (which has b23418cd6494b90a20204b11f6cdb1f2bfd3877b, change
vc_compile_for_all_implementations macro to use normal cmake compilation,
which makes the small example app build), but that didn't build with our
code: https://paste.kde.org/pysb0rhgk
Ah good. That looks like we're almost there. All you're missing (according to
the error output) is the -fabi-version flag. I wonder why/how that got
dropped, though.
The -fabi-version flag is in ${Vc_DEFINITIONS} (which should rather be called
compile flags...).
Cheers,
Matthias
--
─
Dipl.-Phys. Matthias Kretz
Web: http://compeng.uni-frankfurt.de/?mkretz
SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
─
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Problem using Vc with CMake 3.0 and kf5
Hi, On Monday 25 May 2015 11:50:35 Alex Merry wrote: The issue here is that Vc's macros implicitly assume that all compilation flags (including include paths) are done at the directory level (with include_directories() and setting CMAKE_CXX_FLAGS etc), while CMake is moving towards doing things at the target level (with target_include_directories(), target_compile_options() and inheritance from targets passed to target_link_libraries()). I have to admit I didn't know about this change in cmake. I think it's the right direction, though. I just started to read the relevant cmake documentation and then I'll see whether I can figure something out to make the macro work for target-based compiler flags. Cheers, Matthias -- ─ Dipl.-Phys. Matthias Kretz Web: http://compeng.uni-frankfurt.de/?mkretz SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc ─ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Detecting Phonon version
On Sunday 03 May 2009 13:33:19 Allen Winter wrote: On Saturday 02 May 2009 5:33:29 am Thiago Macieira wrote: Hi I was trying to build kdereview/mplayerthumbs and it requires Phonon 4.4 (i.e., the trunk/kdesupport version), which is still unreleased. However, I don't see any checks for the version number anywhere. FindPhonon.cmake does print the version number, which means the checking is possible. But my question is: should we change this? Or should we simply expect that people use the Phonon version that was (or will be) released alongside that KDE version, or later? Seems a question for the Release Team and Matthias: Do we require Phonon 4.4 for KDE 4.3? I'm not planning a Phonon release. Probably Qt Software will do the next Phonon feature release together with Qt 4.6. So, KDE 4.3 should require Phonon 4.3. Everything else needs to be optional (I already told Marco about this for mplayerthumbs). Regards, Matthias -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4 corner issues - what lerned from qt-creator port
On Tuesday 24 March 2009 19:36:19 Helio Chissini de Castro wrote: 4 - w.cpp have an internal Q_OBJECT class and includes w.h with other class with Q_OBJECT but have no moc includes. Not sure I understand. If the class declaration is in w.cpp but no moc included how do you compile a moc file generated from that w.cpp file? Because in order to compile the generated moc file you need the class declaration, but that's only in w.cpp which you can't include from the moc... So what am I missing? -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make clean doesn't delete moc files
Hi, On Wednesday 11 February 2009 19:33:52 Andreas Pakulat wrote: On 06.02.09 09:27:25, Matthias Kretz wrote: Hi, fixed with rev. 922011 of kdesupport/automoc Doesn't work here, I still get such errors from moc-files that were generated with qt 4.4. automoc is up-to-date. You didn't forget the make clean step? :-) Give me more information... e.g. go to a dir where make clean; make fails. Then look whether the *_automoc.cpp files are deleted properly by make clean. If yes, run VERBOSE=1 make and look for some hint why it breaks. Regards, Matthias -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make clean doesn't delete moc files
Hi, On Wednesday 11 February 2009 20:20:03 Andreas Pakulat wrote: I had hoped that automoc would automatically be re-run if the moc executable itself changes... That's easy. But you don't really want that. :-) Regards, Matthias -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make clean doesn't delete moc files
Hi, fixed with rev. 922011 of kdesupport/automoc Regards, Matthias -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make clean doesn't delete moc files
Hi,
On Thursday 05 February 2009 18:56:23 Mike Arthur wrote:
On Thursday 05 February 2009 17:53:20 Michael Pyne wrote:
On Thursday 05 February 2009, David Faure wrote:
Shouldn't it?
Yes, it should. Probably some flag that needs to be added in Automoc to
cause CMake to add them to the list of files to be cleaned?
SET_DIRECTORY_PROPERTIES(PROPERTIES
ADDITIONAL_MAKE_CLEAN_FILES ${VariableContainingMocFiles})
That'll do it.
It sounds too easy. But reality is that the cmake scripts don't know what moc
files exist/will be created. The only one that knows is the automoc
executable. So that one could delete the files once cmake gets support for
running an external command on make clean. For now it can only delete files -
without globbing...
ideas how to delete the moc files are welcome
BTW, deleting the moc files is not important to get a clean build. If you do a
make clean automoc will recreate all moc files, regardless of whether they
exist already. So removing the moc files is only interesting for in source
builds.
Regards,
Matthias
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make clean doesn't delete moc files
Hi, On Thursday 05 February 2009 20:10:37 David Faure wrote: On Thursday 05 February 2009, Matthias Kretz wrote: BTW, deleting the moc files is not important to get a clean build. If you do a make clean automoc will recreate all moc files, regardless of whether they exist already. Nope, that's not the case. Otherwise I wouldn't have asked for it ;) Hmm, Automoc4Config adds konq_automoc.cpp to the ADDITIONAL_MAKE_CLEAN_FILES. And if kde4automoc.cpp finds that konq_automoc.cpp doesn't exist it sets generateAll = true and does so... and only when all moc files are done konq_automoc.cpp is created, making it impossible to break it via Ctrl+C. Any ideas where this goes wrong? Regards, Matthias -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: wildcards in DEPENDS
On Monday 01 December 2008 14:49:56 Matthias Kretz wrote:
I'll come up with a patch to keep compatibility where possible but switch
to automoc targets when possible.
Attached patch keeps compatibility AFAICS but switches to automoc-per-target
everywhere.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
Index: kdesupport/automoc/Automoc4Config.cmake
===
--- kdesupport/automoc/Automoc4Config.cmake (revision 886850)
+++ kdesupport/automoc/Automoc4Config.cmake (working copy)
@@ -134,17 +134,20 @@
configure_file(${_AUTOMOC4_CURRENT_DIR}/automoc4.files.in ${_automoc_dotFiles})
add_custom_target(${_target_NAME}
- ALL
COMMAND ${AUTOMOC4_EXECUTABLE}
${_automoc_source}
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}
${QT_MOC_EXECUTABLE}
${CMAKE_COMMAND}
- DEPENDS ${_automoc_dotFiles} ${_AUTOMOC4_EXECUTABLE_DEP} ${_moc_headers} ${${_SRCS}}
COMMENT
VERBATIM
)
+
+ if(_AUTOMOC4_EXECUTABLE_DEP)
+ add_dependencies(${_target_NAME} ${_AUTOMOC4_EXECUTABLE_DEP})
+ endif(_AUTOMOC4_EXECUTABLE_DEP)
+
set_source_files_properties(${_automoc_source} PROPERTIES GENERATED TRUE)
set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ${_automoc_source})
set(${_SRCS} ${_automoc_source} ${${_SRCS}})
@@ -163,15 +166,9 @@
endif(_index GREATER -1)
endforeach(_argName)
- if(MSVC)
- add_automoc4_target(${_target_NAME}_automoc _SRCS)
- else(MSVC)
- automoc4(${_target_NAME} _SRCS)
- endif(MSVC)
+ add_automoc4_target(${_target_NAME}_automoc _SRCS)
add_executable(${_target_NAME} ${_add_executable_param} ${_SRCS})
- if(MSVC)
- add_dependencies(${_target_NAME} ${_target_NAME}_automoc)
- endif(MSVC)
+ add_dependencies(${_target_NAME} ${_target_NAME}_automoc)
endmacro(AUTOMOC4_ADD_EXECUTABLE)
macro(AUTOMOC4_ADD_LIBRARY _target_NAME)
@@ -186,13 +183,7 @@
endif(_index GREATER -1)
endforeach(_argName)
- if(MSVC)
- add_automoc4_target(${_target_NAME}_automoc _SRCS)
- else(MSVC)
- automoc4(${_target_NAME} _SRCS)
- endif(MSVC)
+ add_automoc4_target(${_target_NAME}_automoc _SRCS)
add_library(${_target_NAME} ${_add_executable_param} ${_SRCS})
- if(MSVC)
- add_dependencies(${_target_NAME} ${_target_NAME}_automoc)
- endif(MSVC)
+ add_dependencies(${_target_NAME} ${_target_NAME}_automoc)
endmacro(AUTOMOC4_ADD_LIBRARY)
Index: kdesupport/automoc/Automoc4Version.cmake
===
--- kdesupport/automoc/Automoc4Version.cmake (revision 886850)
+++ kdesupport/automoc/Automoc4Version.cmake (working copy)
@@ -1,7 +1,7 @@
# set the current version number
set(AUTOMOC4_VERSION_MAJOR 0)
set(AUTOMOC4_VERSION_MINOR 9)
-set(AUTOMOC4_VERSION_PATCH 87)
+set(AUTOMOC4_VERSION_PATCH 88)
set(AUTOMOC4_VERSION ${AUTOMOC4_VERSION_MAJOR}.${AUTOMOC4_VERSION_MINOR}.${AUTOMOC4_VERSION_PATCH})
Index: kdelibs/cmake/modules/FindKDE4Internal.cmake
===
--- kdelibs/cmake/modules/FindKDE4Internal.cmake (revision 891266)
+++ kdelibs/cmake/modules/FindKDE4Internal.cmake (working copy)
@@ -291,6 +291,7 @@
set(AUTOMOC4_VERSION 0.9.83)
endif (NOT AUTOMOC4_VERSION)
macro_ensure_version(0.9.87 ${AUTOMOC4_VERSION} _automoc4_version_ok)
+macro_ensure_version(0.9.88 ${AUTOMOC4_VERSION} _automoc4_version_better)
# for compatibility with KDE 4.0.x
set(KDE4_AUTOMOC_EXECUTABLE${AUTOMOC4_EXECUTABLE} )
@@ -314,17 +315,19 @@
return()
endif(NOT QT4_FOUND)
-if(NOT AUTOMOC4_FOUND OR NOT _automoc4_version_ok)
- if(NOT AUTOMOC4_FOUND)
- message(${_REQ_STRING_KDE4_MESSAGE} KDE4 not found, because Automoc4 not found.)
- return()
- else(NOT AUTOMOC4_FOUND)
+if(NOT AUTOMOC4_FOUND)
+ message(${_REQ_STRING_KDE4_MESSAGE} KDE4 not found, because Automoc4 not found.)
+ return()
+else(NOT AUTOMOC4_FOUND)
+ if(NOT _automoc4_version_better)
if(NOT _automoc4_version_ok)
message(${_REQ_STRING_KDE4_MESSAGE} Your version of automoc4 is too old. You have ${AUTOMOC4_VERSION}, you need at least 0.9.87)
return()
+ else(NOT _automoc4_version_ok)
+ message(STATUS Your version of automoc4 is old. You have ${AUTOMOC4_VERSION}, it is recommended to upgrade to 0.9.88)
endif(NOT _automoc4_version_ok)
- endif(NOT AUTOMOC4_FOUND)
-endif(NOT AUTOMOC4_FOUND OR NOT _automoc4_version_ok)
+ endif(NOT _automoc4_version_better)
+endif(NOT AUTOMOC4_FOUND)
# now we are sure we have everything we need
Index: kdelibs/cmake/modules/KDE4Macros.cmake
===
--- kdelibs/cmake/modules/KDE4Macros.cmake (revision 891266)
+++ kdelibs/cmake/modules
Re: wildcards in DEPENDS
On Tuesday 25 November 2008 22:35:34 Alexander Neundorf wrote:
The macro macro_add_file_dependencies() is only available in kdelibs/ and
projects using kdelibs/, i.e. it shouldn't be used in automoc. The macro is
in kdelibs/cmake/modules/MacroAddFileDependencies.cmake, you can just copy
it.
Hmm, I found the macro also in the cmake installation dir as the FindQt4
shipping with cmake also uses it.
But, why is this dependency required now ? Currently the source files don't
depend on the automoc-generated file and it works ?
Yes it works most of the time except for make target/fast there's a race and
it breaks sometimes.
So actually this part of the patch is not directly related to the
automoc4_init change.
About the add_custom_target(automoc4_init): this is done now
unconditionally. I.e. if you do find_package(Automoc4) twice, it will be
executed twice, cmake will then complain about the target being added
twice.
Ah, I thought cmake would still read the automoc code only once.
So you should test wether the target has already been added.
With CMake = 2.6.2 you can do
if(NOT TARGET automoc4_init)
...
With version before that you can do
get_target_property(AUTOMOC4_INIT_TYPE automoc4_init TYPE)
if the target has already been created, you will get UTILITY as result
(which is TRUE if tested in an if()), and AUTOMOC4_INIT_TYPE-NOTFOUND if
it hasn't been created yet (which is false if tested with if()).
I used if(AUTOMOC4_INIT_FILE) now, that should be suffiently safe and a bit
easier, ok?
Is it still necessary to have different versions for Windows and
non-Windows ?
I don't know. I'd like the Windows people to give the non-Windows code another
try and hopefully we can remove the special casing for Windows again.
Instead of putting all files into automoc4_init.files on every cmake run,
could you do it similar to as you did it before ?
I.e. instead if touching the file in the add_custom_command(), add that
filename to automoc4_init.files, so in the next make, the automoc4_init
target will just touch these files and not all ?
This could be done by adding that to the automoc4 executable or by
executing an additional command in the same add_custom_command (echo should
work)
It's hard to do that without creating new races. (Think of the user hitting
Ctrl+C at the most inconvenient point in time.) And what would happen if two
or more automoc4 processes write to the file at the same time?
Also the current implementation seems reasonably fast (kdelibs: 3ms, kdebase:
4ms, phonon: 0ms. After 'echo 3 /proc/sys/vm/drop_caches': kdelibs: 77ms,
kdebase: 260ms, phonon: 27ms.)
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
Index: kde4automoc.cpp
===
--- kde4automoc.cpp (revision 886850)
+++ kde4automoc.cpp (working copy)
@@ -34,6 +34,7 @@
#include QtCore/QRegExp
#include QtCore/QStringList
#include QtCore/QTextStream
+//#include QtCore/QTime
#include QtCore/QtDebug
#include cstdlib
#include sys/types.h
@@ -60,7 +61,6 @@
void dotFilesCheck(bool);
void lazyInitMocDefinitions();
void lazyInit();
-bool touch(const QString filename);
bool generateMoc(const QString sourceFile, const QString mocFileName);
void printUsage(const QString );
void printVersion();
@@ -87,12 +87,12 @@
bool failed;
bool automocCppChanged;
bool generateAll;
-bool doTouch;
};
void AutoMoc::printUsage(const QString path)
{
-cout Usage: path outfile srcdir builddir moc executable cmake executable [--touch] endl;
+cout Usage: path outfile srcdir builddir moc executable cmake executable endl;
+cout or: path --touch file containing filepaths to touch endl;
}
void AutoMoc::printVersion()
@@ -119,7 +119,7 @@
AutoMoc::AutoMoc()
: verbose(!qgetenv(VERBOSE).isEmpty()), cerr(stderr), cout(stdout), failed(false),
-automocCppChanged(false), generateAll(false), doTouch(false)
+automocCppChanged(false), generateAll(false)
{
const QByteArray colorEnv = qgetenv(COLOR);
cmakeEchoColorArgs QLatin1String(-E) QLatin1String(cmake_echo_color)
@@ -163,12 +163,6 @@
mocExe = args[4];
cmakeExecutable = args[5];
-if (args.size() 6) {
-if (args[6] == QLatin1String(--touch)) {
-doTouch = true;
-}
-}
-
lazyInitMocDefinitions();
QByteArray line = dotFiles.readLine();
@@ -235,8 +229,31 @@
printUsage(args[0]);
::exit(EXIT_FAILURE);
}
-}
-else if (args.size() 5) {
+} else if (args.size() == 3) {
+if (args[1] != --touch) {
+printUsage(args[0]);
+::exit(EXIT_FAILURE);
+}
+//QTime stopwatch;
+//stopwatch.start();
+QFile filesFile(args[2
Re: wildcards in DEPENDS
On Thursday 20 November 2008 11:56:03 Matthias Kretz wrote: On Thursday 20 November 2008 10:27:11 Matthias Kretz wrote: Now, for some reason qt4_generate_moc stopped working for me. I don't see how that could be related, if it is and you have an idea please take a look. It seems I found the problem: the OBJECT_DEPENDS I added in Automoc4Config overwrites the OBJECT_DEPENDS from qt4_generate_moc. I changed automoc to also use macro_add_file_dependency now and kdelibs compiles again. New atuomoc patch attached. I'd like to commit this, please review. OK to commit? -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: wildcards in DEPENDS
On Wednesday 19 November 2008 14:49:10 Matthias Kretz wrote:
On Tuesday 18 November 2008 20:55:11 Alexander Neundorf wrote:
What do you think about the idea with the one global helper target ?
Sounds like a good idea but I have two problems with it:
a) it won't get called on make target/fast
b) there are still race conditions in your proposal such that in the end
_automoc.cpp is newer than _automoc.cpp.files and the helper target will
not be instructed to touch _automoc.cpp.files.
I now have a patch that creates an automoc4_init target globally and all other
targets using automoc depend on it.
This target runs
autmoc4 --touch ${CMAKE_BINARY_DIR}/automoc4_init.files
The file it opens contains a list of all the filepaths to the
*_automoc.cpp.files of the project.
So when automoc4_init is executed all automoc custom commands are made out-of-
date. There's also no race with this anymore.
make target/fast will work most of the time. Until _automoc.cpp gets changed
and has a newer timestamp than _automoc.cpp.files. Then you need to run a
non-/fast make and it'll work again.
Now, for some reason qt4_generate_moc stopped working for me. I don't see how
that could be related, if it is and you have an idea please take a look.
Patch attached.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
Index: kde4automoc.cpp
===
--- kde4automoc.cpp (revision 886566)
+++ kde4automoc.cpp (working copy)
@@ -60,7 +60,6 @@
void dotFilesCheck(bool);
void lazyInitMocDefinitions();
void lazyInit();
-bool touch(const QString filename);
bool generateMoc(const QString sourceFile, const QString mocFileName);
void printUsage(const QString );
void printVersion();
@@ -87,12 +86,12 @@
bool failed;
bool automocCppChanged;
bool generateAll;
-bool doTouch;
};
void AutoMoc::printUsage(const QString path)
{
-cout Usage: path outfile srcdir builddir moc executable cmake executable [--touch] endl;
+cout Usage: path outfile srcdir builddir moc executable cmake executable endl;
+cout or: path --touch file containing filepaths to touch endl;
}
void AutoMoc::printVersion()
@@ -119,7 +118,7 @@
AutoMoc::AutoMoc()
: verbose(!qgetenv(VERBOSE).isEmpty()), cerr(stderr), cout(stdout), failed(false),
-automocCppChanged(false), generateAll(false), doTouch(false)
+automocCppChanged(false), generateAll(false)
{
const QByteArray colorEnv = qgetenv(COLOR);
cmakeEchoColorArgs QLatin1String(-E) QLatin1String(cmake_echo_color)
@@ -163,12 +162,6 @@
mocExe = args[4];
cmakeExecutable = args[5];
-if (args.size() 6) {
-if (args[6] == QLatin1String(--touch)) {
-doTouch = true;
-}
-}
-
lazyInitMocDefinitions();
QByteArray line = dotFiles.readLine();
@@ -235,8 +228,28 @@
printUsage(args[0]);
::exit(EXIT_FAILURE);
}
-}
-else if (args.size() 5) {
+} else if (args.size() == 3) {
+if (args[1] != --touch) {
+printUsage(args[0]);
+::exit(EXIT_FAILURE);
+}
+QFile filesFile(args[2]);
+filesFile.open(QIODevice::ReadOnly | QIODevice::Text);
+QByteArray line = filesFile.readLine().trimmed();
+while (!line.isEmpty()) {
+#ifdef Q_OS_WIN
+_wutime(reinterpret_castconst wchar_t *(QString::fromLocal8Bit(line).utf16()), 0);
+#else
+int err = utime(line.constData(), NULL);
+if (err == -1) {
+err = errno;
+cerr strerror(err) \n;
+}
+#endif
+line = filesFile.readLine().trimmed();
+}
+::exit(0);
+} else if (args.size() != 6) {
printUsage(args[0]);
::exit(EXIT_FAILURE);
}
@@ -514,38 +527,11 @@
outfile.write(automocSource);
outfile.close();
-// update the timestamp on the _automoc.cpp.files file to make sure we get called again
dotFiles.close();
-if (doTouch !touch(dotFiles.fileName())) {
-return false;
-}
return true;
}
-bool AutoMoc::touch(const QString _filename)
-{
-// sleep for 1s in order to make the modification time greater than the modification time of
-// the files written before. Equal modification time is not good enough. Just using utime with
-// time(NULL) + 1 is also not a good solution as then make will complain about clock skew.
-#ifdef Q_OS_WIN
-Sleep(1000);
-_wutime(reinterpret_castconst wchar_t *(_filename.utf16()), 0);
-#else
-const QByteArray filename = QFile::encodeName(_filename);
-const struct timespec sleepDuration = { 1, 0 };
-nanosleep(sleepDuration, NULL);
-
-int err = utime(filename.constData(), NULL);
-if (err == -1) {
-err = errno
Re: wildcards in DEPENDS
On Thursday 20 November 2008 10:27:11 Matthias Kretz wrote:
Now, for some reason qt4_generate_moc stopped working for me. I don't see
how that could be related, if it is and you have an idea please take a
look.
It seems I found the problem:
the OBJECT_DEPENDS I added in Automoc4Config overwrites the OBJECT_DEPENDS
from qt4_generate_moc. I changed automoc to also use macro_add_file_dependency
now and kdelibs compiles again.
New atuomoc patch attached. I'd like to commit this, please review.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
Index: kde4automoc.cpp
===
--- kde4automoc.cpp (revision 886850)
+++ kde4automoc.cpp (working copy)
@@ -60,7 +60,6 @@
void dotFilesCheck(bool);
void lazyInitMocDefinitions();
void lazyInit();
-bool touch(const QString filename);
bool generateMoc(const QString sourceFile, const QString mocFileName);
void printUsage(const QString );
void printVersion();
@@ -87,12 +86,12 @@
bool failed;
bool automocCppChanged;
bool generateAll;
-bool doTouch;
};
void AutoMoc::printUsage(const QString path)
{
-cout Usage: path outfile srcdir builddir moc executable cmake executable [--touch] endl;
+cout Usage: path outfile srcdir builddir moc executable cmake executable endl;
+cout or: path --touch file containing filepaths to touch endl;
}
void AutoMoc::printVersion()
@@ -119,7 +118,7 @@
AutoMoc::AutoMoc()
: verbose(!qgetenv(VERBOSE).isEmpty()), cerr(stderr), cout(stdout), failed(false),
-automocCppChanged(false), generateAll(false), doTouch(false)
+automocCppChanged(false), generateAll(false)
{
const QByteArray colorEnv = qgetenv(COLOR);
cmakeEchoColorArgs QLatin1String(-E) QLatin1String(cmake_echo_color)
@@ -163,12 +162,6 @@
mocExe = args[4];
cmakeExecutable = args[5];
-if (args.size() 6) {
-if (args[6] == QLatin1String(--touch)) {
-doTouch = true;
-}
-}
-
lazyInitMocDefinitions();
QByteArray line = dotFiles.readLine();
@@ -235,8 +228,28 @@
printUsage(args[0]);
::exit(EXIT_FAILURE);
}
-}
-else if (args.size() 5) {
+} else if (args.size() == 3) {
+if (args[1] != --touch) {
+printUsage(args[0]);
+::exit(EXIT_FAILURE);
+}
+QFile filesFile(args[2]);
+filesFile.open(QIODevice::ReadOnly | QIODevice::Text);
+QByteArray line = filesFile.readLine().trimmed();
+while (!line.isEmpty()) {
+#ifdef Q_OS_WIN
+_wutime(reinterpret_castconst wchar_t *(QString::fromLocal8Bit(line).utf16()), 0);
+#else
+int err = utime(line.constData(), NULL);
+if (err == -1) {
+err = errno;
+cerr strerror(err) \n;
+}
+#endif
+line = filesFile.readLine().trimmed();
+}
+::exit(0);
+} else if (args.size() != 6) {
printUsage(args[0]);
::exit(EXIT_FAILURE);
}
@@ -514,38 +527,11 @@
outfile.write(automocSource);
outfile.close();
-// update the timestamp on the _automoc.cpp.files file to make sure we get called again
dotFiles.close();
-if (doTouch !touch(dotFiles.fileName())) {
-return false;
-}
return true;
}
-bool AutoMoc::touch(const QString _filename)
-{
-// sleep for 1s in order to make the modification time greater than the modification time of
-// the files written before. Equal modification time is not good enough. Just using utime with
-// time(NULL) + 1 is also not a good solution as then make will complain about clock skew.
-#ifdef Q_OS_WIN
-Sleep(1000);
-_wutime(reinterpret_castconst wchar_t *(_filename.utf16()), 0);
-#else
-const QByteArray filename = QFile::encodeName(_filename);
-const struct timespec sleepDuration = { 1, 0 };
-nanosleep(sleepDuration, NULL);
-
-int err = utime(filename.constData(), NULL);
-if (err == -1) {
-err = errno;
-cerr strerror(err) \n;
-return false;
-}
-#endif
-return true;
-}
-
bool AutoMoc::generateMoc(const QString sourceFile, const QString mocFileName)
{
//qDebug() Q_FUNC_INFO sourceFile mocFileName;
Index: Automoc4Config.cmake
===
--- Automoc4Config.cmake (revision 886850)
+++ Automoc4Config.cmake (working copy)
@@ -1,5 +1,5 @@
-
+include(MacroAddFileDependencies)
get_filename_component(_AUTOMOC4_CURRENT_DIR ${CMAKE_CURRENT_LIST_FILE} PATH)
# set the automoc version number
@@ -37,6 +37,18 @@
endif(_headers_to_moc)
endmacro (AUTOMOC4_MOC_HEADERS)
+set(AUTOMOC4_INIT_FILE ${CMAKE_BINARY_DIR}/automoc4_init.files)
+add_custom_target(automoc4_init
Re: wildcards in DEPENDS
Hi,
On Tuesday 18 November 2008 20:55:11 Alexander Neundorf wrote:
On Tuesday 18 November 2008, Matthias Kretz wrote:
is it portable to use wildcards in DEPENDS? Like in
add_custom_command(OUTPUT ${_automoc_source}
COMMAND ${AUTOMOC4_EXECUTABLE}
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/*
COMMENT
VERBATIM
)
This seems to be a better solution to get automoc4 to run whenever it's
needed (I'll add some more dependencies than the above, but the * part is
what I'm wondering about).
Did you try ?
I would expect that it doesn't work.
And if it works, it works probably only because of how GNU make interpretes
the makefiles. I guess it also wouldn't work for files in subdirs ?
I tried on Linux as GNU make documents wildcards to work in dependencies. And
yes, it works like I want it to.
I have the feeling my --touch hack is too fragile for the real world, as
can be seen with the many problem reports about kwordwraptest. It happens
because the timestamps of kwordwraptest_automoc.cpp and
kwordwraptest_automoc.cpp.files tell make that automoc4 doesn't need to
run. Though my intention was that .files is always more recent than the
.cpp...
Maybe this is caused by the behaviour of usleep() not to sleep as long as
expected ?
I don't really know how it could happen other than a race condition when
pressing Ctrl+C.
Yesterday I also remembered why you don't see every automoc4 call take 1s.
It's because the touch is only necessary when the _automoc.cpp file is newer
than the _automoc.cpp.files file. Which doesn't happen that often on update +
recompile.
What do you think about the idea with the one global helper target ?
Sounds like a good idea but I have two problems with it:
a) it won't get called on make target/fast
b) there are still race conditions in your proposal such that in the end
_automoc.cpp is newer than _automoc.cpp.files and the helper target will not
be instructed to touch _automoc.cpp.files.
Regards,
Matthias
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: installing and finding cmake-built projects
On Tuesday 18 November 2008 11:00:42 Mark Constable wrote: On 2008-11-18, Thiago Macieira wrote: Ah. speaking of which. Could you possibly perhaps rename kde's or qt's ? phonon.pc file. They're both named the same thing and overwrite each other. Don't install both. They also produce the same libraries and the same include headers. Are you sure about this? For example, doesn't KDE's phonon include libxine but Qt's version does not ? We were talking about libphonon. That code/library is in KDE's svn and Qt has a copy of it. So installing both doesn't make sense (unless you're a developer testing multiple versions). It's correct that KDE provides the phonon-xine backend and Qt doesn't ship it, but I don't see how that's related to the phonon.pc file. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
wildcards in DEPENDS
Hi,
is it portable to use wildcards in DEPENDS? Like in
add_custom_command(OUTPUT ${_automoc_source}
COMMAND ${AUTOMOC4_EXECUTABLE}
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/*
COMMENT
VERBATIM
)
This seems to be a better solution to get automoc4 to run whenever it's needed
(I'll add some more dependencies than the above, but the * part is what I'm
wondering about).
I have the feeling my --touch hack is too fragile for the real world, as can
be seen with the many problem reports about kwordwraptest. It happens because
the timestamps of kwordwraptest_automoc.cpp and
kwordwraptest_automoc.cpp.files tell make that automoc4 doesn't need to run.
Though my intention was that .files is always more recent than the .cpp...
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: installing and finding cmake-built projects
On Sunday 16 November 2008 20:21:15 Alexander Neundorf wrote: I think we should do it this way for all projects in kdesupport/. Yes, I thought about doing that for Phonon, but then what about a Phonon shipped with Qt or an older Phonon installation that didn't come with the PhononConfig.cmake file? -- Matthias Kretz (Germany) http://Vir.homelinux.org/ ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Patch to regenerate all moc files when -D flags change
Hi,
ok, if I commit the attached patch to automoc? (see subject :-) )
One question: should I regenerate all moc files once people update to this
version or not? The former is very safe but results in a full recompilation of
everything, the latter is reasonably safe, but still results in a change to
all automoc_target.cpp files = relinking of all targets.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: kde4automoc.cpp
===
--- kde4automoc.cpp (revision 842595)
+++ kde4automoc.cpp (working copy)
@@ -58,6 +58,7 @@
private:
void dotFilesCheck(bool);
+void lazyInitMocDefinitions();
void lazyInit();
bool touch(const QString filename);
bool generateMoc(const QString sourceFile, const QString mocFileName);
@@ -118,7 +119,7 @@
AutoMoc::AutoMoc()
: verbose(!qgetenv(VERBOSE).isEmpty()), cerr(stderr), cout(stdout), failed(false),
-automocCppChanged(false), doTouch(false)
+automocCppChanged(false), generateAll(false), doTouch(false)
{
const QByteArray colorEnv = qgetenv(COLOR);
cmakeEchoColorArgs QLatin1String(-E) QLatin1String(cmake_echo_color)
@@ -126,18 +127,13 @@
QLatin1String(--bold);
}
-void AutoMoc::lazyInit()
+void AutoMoc::lazyInitMocDefinitions()
{
-const QStringList args = QCoreApplication::arguments();
-mocExe = args[4];
-cmakeExecutable = args[5];
-
-if (args.size() 6) {
-if (args[6] == QLatin1String(--touch)) {
-doTouch = true;
-}
+static bool done = false;
+if (done) {
+return;
}
-
+done = true;
QByteArray line = dotFiles.readLine();
dotFilesCheck(line == MOC_COMPILE_DEFINITIONS:\n);
line = dotFiles.readLine().trimmed();
@@ -159,8 +155,23 @@
}
}
}
+}
-line = dotFiles.readLine();
+void AutoMoc::lazyInit()
+{
+const QStringList args = QCoreApplication::arguments();
+mocExe = args[4];
+cmakeExecutable = args[5];
+
+if (args.size() 6) {
+if (args[6] == QLatin1String(--touch)) {
+doTouch = true;
+}
+}
+
+lazyInitMocDefinitions();
+
+QByteArray line = dotFiles.readLine();
dotFilesCheck(line == MOC_INCLUDES:\n);
line = dotFiles.readLine().trimmed();
const QStringList incPaths = QString::fromUtf8(line).split(';', QString::SkipEmptyParts);
@@ -241,8 +252,6 @@
builddir += '/';
}
-generateAll = !outfile.exists();
-
dotFiles.setFileName(args[1] + QLatin1String(.files));
dotFiles.open(QIODevice::ReadOnly | QIODevice::Text);
@@ -250,6 +259,24 @@
dotFilesCheck(line == SOURCES:\n);
const QStringList sourceFiles = QString::fromUtf8(dotFiles.readLine().trimmed()).split(';', QString::SkipEmptyParts);
+if (outfile.exists()) {
+// set generateAll = true if MOC_COMPILE_DEFINITIONS changed
+outfile.open(QIODevice::ReadOnly | QIODevice::Text);
+const QByteArray buf = outfile.readLine();
+if (buf.endsWith(*/)) {
+// it's an old file, which doesn't contain mocDefinitions info
+generateAll = true;
+} else {
+QByteArray buf = outfile.readLine();
+buf.chop(1); // remove trailing \n
+lazyInitMocDefinitions();
+generateAll = (buf != mocDefinitions.join(QString(QLatin1Char(' '))).toUtf8());
+}
+outfile.close();
+} else {
+generateAll = true;
+}
+
// the program goes through all .cpp files to see which moc files are included. It is not really
// interesting how the moc file is named, but what file the moc is created from. Once a moc is
// included the same moc may not be included in the _automoc.cpp file anymore. OTOH if there's a
@@ -449,7 +476,8 @@
QByteArray automocSource;
QTextStream outStream(automocSource, QIODevice::WriteOnly);
-outStream /* This file is autogenerated, do not edit */\n;
+outStream /* This file is autogenerated, do not edit\n
+ mocDefinitions.join(QString(QLatin1Char(' '))) \n*/\n;
if (notIncludedMocs.isEmpty()) {
outStream enum some_compilers { need_more_than_nothing };\n;
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Patch to remove parallel moc execution
On Friday 18 July 2008 12:32:55 Matthias Kretz wrote: Hi, attached is a patch to make automoc4 execute cmake and moc serially. This simplifies the code, removes a special casing for FreeBSD and probably doesn't have much impact on execution time (as e.g. -j4 still lets make call 4 jobs, like 4 automoc4 processes in parallel). If you want to profile it, you're welcome. :-) OK to commit? I didn't get a go ahead, yet. Now that KDE 4.1 (or rather automoc4 0.9.84) is out, do you think it's ok to commit this patch? -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Patch to add two more automoc4 convenience macros
Hi,
for all the automoc4 users that cannot use KDE4Macros.cmake I'd like to add
the following two macros:
macro(ADD_AUTOMOC4_EXECUTABLE _target_NAME)
set(_SRCS ${ARGN})
set(_add_executable_param)
foreach(_argName WIN32 MACOSX_BUNDLE EXCLUDE_FROM_ALL)
list(GET _SRCS 0 _arg)
if(_arg STREQUAL _argName)
list(APPEND _add_executable_param ${_argName})
list(REMOVE_AT _SRCS 0)
endif(_arg STREQUAL _argName)
endforeach(_argName)
if(MSVC)
add_automoc4_target(${_target_NAME}_automoc _SRCS)
else(MSVC)
automoc4(${_target_NAME} _SRCS)
endif(MSVC)
add_executable(${_target_NAME} ${_add_executable_param} ${_SRCS})
if(MSVC)
add_dependencies(${_target_NAME} ${_target_NAME}_automoc)
endif(MSVC)
endmacro(ADD_AUTOMOC4_EXECUTABLE)
macro(ADD_AUTOMOC4_LIBRARY _target_NAME)
set(_SRCS ${ARGN})
set(_add_executable_param)
foreach(_argName STATIC SHARED MODULE EXCLUDE_FROM_ALL)
list(GET _SRCS 0 _arg)
if(_arg STREQUAL _argName)
list(APPEND _add_executable_param ${_argName})
list(REMOVE_AT _SRCS 0)
endif(_arg STREQUAL _argName)
endforeach(_argName)
if(MSVC)
add_automoc4_target(${_target_NAME}_automoc _SRCS)
else(MSVC)
automoc4(${_target_NAME} _SRCS)
endif(MSVC)
add_library(${_target_NAME} ${_add_executable_param} ${_SRCS})
if(MSVC)
add_dependencies(${_target_NAME} ${_target_NAME}_automoc)
endif(MSVC)
endmacro(ADD_AUTOMOC4_LIBRARY)
AFAICS we could then also switch the macros in KDE4Macros.cmake to use this.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Patch for KDE4Macros to use extra target on Windows
On Friday 18 July 2008 23:38:45 Brad King wrote: Matthias Kretz wrote: attached is a patch to use the new automoc macro which adds a new target per default on Windows. Can someone point me to discussion of the original problem, please? I think most of this was in german and private mail. So here's a summary: I changed the automoc4 invocation (ADD_CUSTOM_COMMAND) to only depend on one file (i.e. target_automoc.cpp.files). I wanted to achieve that automoc4 gets called unconditionally, but without creating a new target. That's why a run of automoc4 now touches the file it depends on, one second after it touches its output file. - With that make does what I want: execute automoc4 once per target on every call to make. If automoc4 decides there's nothing to do it doesn't touch any files and so make decides not to recompile the output file of automoc4. - nmake seems to behave different in the last point: it thinks that if the output of automoc4 is a source file and automoc4 got called it has to recompile that source file, no matter whether automoc4 changed the timestamp or not. IIUC nmake internally updates the timestamp of the output source file and doesn't even look whether that corresponds with what happened on the filesystem. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Patch for KDE4Macros to use extra target on Windows
On Saturday 19 July 2008 12:52:57 Christian Ehrlicher wrote:
Matthias Kretz schrieb:
Hi,
attached is a patch to use the new automoc macro which adds a new target
per default on Windows.
Please let me know if that is what you want/need and whether I should
commit this.
The patch doesn't look correct to me:
@@ -672,7 +679,11 @@
target_link_libraries(${_target_NAME} ${QT_QTMAIN_LIBRARY}
kdeinit_${_target_NAME})
else(WIN32)
- kde4_handle_automoc(kdeinit_${_target_NAME} _SRCS)
+ if(WIN32)
+ add_automoc4_target(kdeinit_${_target_NAME}_automoc _SRCS)
+ else(WIN32)
+ automoc4(kdeinit_${_target_NAME} _SRCS)
+ endif(WIN32)
here we're already in the !WIN32 part so the above has no effect for
WIN32 at all.
ups, yes. This was just a stupid search and replace. AFAICS kdeinit targets on
WIN32 don't need automoc, right? So we can just remove this part of the patch.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Patch to remove parallel moc execution
Hi,
attached is a patch to make automoc4 execute cmake and moc serially. This
simplifies the code, removes a special casing for FreeBSD and probably doesn't
have much impact on execution time (as e.g. -j4 still lets make call 4 jobs,
like 4 automoc4 processes in parallel).
If you want to profile it, you're welcome. :-)
OK to commit?
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: kde4automoc.cpp
===
--- kde4automoc.cpp (revision 834164)
+++ kde4automoc.cpp (working copy)
@@ -60,17 +60,16 @@
void lazyInit();
bool touch(const QString filename);
bool generateMoc(const QString sourceFile, const QString mocFileName);
-void waitForProcesses();
void printUsage(const QString );
void printVersion();
void echoColor(const QString msg)
{
-QProcess *cmakeEcho = new QProcess;
-cmakeEcho-setProcessChannelMode(QProcess::ForwardedChannels);
+QProcess cmakeEcho;
+cmakeEcho.setProcessChannelMode(QProcess::ForwardedChannels);
QStringList args(cmakeEchoColorArgs);
args msg;
-cmakeEcho-start(cmakeExecutable, args, QIODevice::NotOpen);
-processes.enqueue(Process(cmakeEcho, QString()));
+cmakeEcho.start(cmakeExecutable, args, QIODevice::NotOpen);
+cmakeEcho.waitForFinished(-1);
}
QString builddir;
@@ -83,13 +82,6 @@
const bool verbose;
QTextStream cerr;
QTextStream cout;
-struct Process
-{
-Process(QProcess *a, const QString b) : qproc(a), mocFilePath(b) {}
-QProcess *qproc;
-QString mocFilePath;
-};
-QQueueProcess processes;
bool failed;
bool automocCppChanged;
bool generateAll;
@@ -436,9 +428,6 @@
}
}
-// let all remaining moc processes finish
-waitForProcesses();
-
if (failed) {
// if any moc process failed we don't want to touch the _automoc.cpp file so that
// automoc4 is rerun until the issue is fixed
@@ -496,27 +485,6 @@
return true;
}
-void AutoMoc::waitForProcesses()
-{
-while (!processes.isEmpty()) {
-Process proc = processes.dequeue();
-
-bool result = proc.qproc-waitForFinished(-1);
-//ignore errors from the cmake echo process
-if (!proc.mocFilePath.isEmpty()) {
-if (!result || proc.qproc-exitCode()) {
-cerr automoc4: process for proc.mocFilePath
- failed: proc.qproc-errorString() endl;
-cerr pid to wait for: proc.qproc-pid() endl;
-cerr processes in queue: processes.size() endl;
-failed = true;
-QFile::remove(proc.mocFilePath);
-}
-}
-delete proc.qproc;
-}
-}
-
bool AutoMoc::generateMoc(const QString sourceFile, const QString mocFileName)
{
//qDebug() Q_FUNC_INFO sourceFile mocFileName;
@@ -533,19 +501,8 @@
echoColor(Generating + mocFileName);
}
-// we don't want too many child processes
-#ifdef Q_OS_FREEBSD
-static const int max_processes = 0;
-#else
-static const int max_processes = 10;
-#endif
-
-if (processes.size() max_processes) {
-waitForProcesses();
-}
-
-QProcess *mocProc = new QProcess;
-mocProc-setProcessChannelMode(QProcess::ForwardedChannels);
+QProcess mocProc;
+mocProc.setProcessChannelMode(QProcess::ForwardedChannels);
QStringList args(mocIncludes + mocDefinitions);
#ifdef Q_OS_WIN
args -DWIN32;
@@ -555,15 +512,21 @@
if (verbose) {
cout mocExe args.join(QLatin1String( )) endl;
}
-mocProc-start(mocExe, args, QIODevice::NotOpen);
-if (mocProc-waitForStarted()) {
-processes.enqueue(Process(mocProc, mocFilePath));
+mocProc.start(mocExe, args, QIODevice::NotOpen);
+if (mocProc.waitForStarted()) {
+const bool result = mocProc.waitForFinished(-1);
+if (!result || mocProc.exitCode()) {
+cerr automoc4: process for mocFilePath
+ failed: mocProc.errorString() endl;
+cerr pid to wait for: mocProc.pid() endl;
+failed = true;
+QFile::remove(mocFilePath);
+}
return true;
} else {
cerr automoc4: process for mocFilePath failed to start:
- mocProc-errorString() endl;
+ mocProc.errorString() endl;
failed = true;
-delete mocProc;
}
}
return false;
Index
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Thursday 05 June 2008, Alexander Neundorf wrote:
On Thursday 29 May 2008, Matthias Kretz wrote:
On Thursday 29 May 2008, Alexander Neundorf wrote:
On Wednesday 28 May 2008, Matthias Kretz wrote:
I tried add_custom_target and it won't work in the automoc macros
because there needs to be a dependency from the main target to the
automoc target. And that cannot be added from the automoc macro
because the main target is not defined at this point.
add_custom_command(TARGET has the same problem.
It would be possible to use add_custom_target and require the user to
add the dependency between the two targets himself. In the KDE4_
macros we could do that...
Yes, there it wouldn't be a problem.
Except that it is a bit slower, right ?
It's hard to profile. But it certainly has to read and write a lot more files
if you double the number of targets in a project. It should be noticable on
big modules like kdelibs and kdebase. Small modules won't notice it, I think.
Do you think this would be acceptable for other projects ?
It being slower or the need to add a dependency rule for a target that fell
from the sky?
Hmm, perhaps the target could be made explicit:
add_automoc4_target(phonon_automoc phonon_SRCS)
add_library(phonon ${phonon_SRCS})
add_dependencies(phonon phonon_automoc)
kde4_add_library/executable/plugin would hide all that.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Monday 19 May 2008, Andras Mantia wrote: On Sunday 18 May 2008, Matthias Kretz wrote: automoc4 uses the include directories as specified by include_directory. At least that's what I wrote and expect the code to do. :-) Take a look at the generated target_automoc.cpp.files file. Its second line contains all the include directories as they'll get passed to moc. This line gets generated by the configure_files call in Automoc4.cmake. You mean the line under MOC_INCLUDES? Yes, it contains the path to kdebase/workspace/libs, but this doesn't change the fact that the installed one is taken and not the one from the kdebase source dir. My question was not whether it contains that path but whether the order in that file is correct or not. Because that tells you whether the error is in automoc or somewhere else. (i.e. correct order in that file = error in automoc4; incorrect order in the file = error in cmake scripts) Just lurk a little on #kde-devel and you will see how many run into this problem. That doesn't help to find the cause either. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [ANNOUNCE] automoc4 from kdesupport now supported for building KDE
On Saturday 17 May 2008, Andras Mantia wrote:
On Sunday 11 May 2008 00:58:38 Alexander Neundorf wrote:
If you experience any problems with automoc, please let us know at
kde-buildsystem@kde.org (or here).
Here is a problem: kdebase fails to build if there are some older
include/solid/control/ifaces around.
The error is:
cd
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7 /opt/kde4/bin/automoc4
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7/solid_networkmanager07_automoc.cpp
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-
0.7
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7 /opt/qt4/bin/moc []
Generating
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7/networkinterface.moc from
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-
0.7/networkinterface.h
/data/development/sources/kde-trunk/kdebase/workspace/solid/networkmanager-
0.7/manager.h:35: Error: Undefined interface
[...]
automoc4: process
for
/data/development/build/kde-trunk/kdebase/workspace/solid/networkmanager-0.
7/manager.moc failed: Unknown error
pid to wait for: 0
processes in queue: 11
The problem is this line in manager.h:
#include solid/control/ifaces/networkmanager.h
This picks up the installed networkmanager.h instead of the one from
kdebase/workspace/libs/solid/control/ifaces .
I tried to add
${CMAKE_SOURCE_DIR}/workspace/libs
to the include_directories, but seems that this is ignored or searched
after the system path.
So the solution to build kdebase is to remove your installed version and
build again.This also does not work if e.g you have KDE 4.0.x installed in
/usr like it is on openSUSE. So you have to:
- remove the old files (e.g from /opt/kde4/include if KDE trunk was
installed there)
- build AND install kdebase/workspace/libs/solid (so the correct headers
are installed to /opt/kde4)
- build now kdebase/workspace/solid
I find this behavior broken, automoc4 should find the header files that are
in kdebase/workspace/libs/solid/control/ifaces as specified by the
include_directory command.
automoc4 uses the include directories as specified by include_directory. At
least that's what I wrote and expect the code to do. :-)
Take a look at the generated target_automoc.cpp.files file. Its second line
contains all the include directories as they'll get passed to moc. This line
gets generated by the configure_files call in Automoc4.cmake.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Thursday 08 May 2008, Alexander Neundorf wrote: Patch attached (automoc.patch): I'm all for committing this. If you consider it ok, feel free to commit. Will do. I'm using this with the other patch against kdelibs/cmake - which makes the rest of KDE use the automoc from kdesupport. I want to have a look at that in the next day. Actually we must not remove anything from FindKDE4Internal.cmake (as e.g. KDE4_AUTOMOC), since this breaks source compatiblity. I'm not sure about the KDE4_SET/GET_TARGET_PROPERTY(), I don't think anybody else uses them. But anyway, I want to see if I can make it so that automoc4 is optional for a few weeks and if it's not found the one from kdelibs is used. This way developers will have more time to update. So please don't commit this one yet. Yes, I considered my patch good enough for testing, not more. I considered the removal of KDE4_AUTOMOC_EXECUTABLE from FindKDE4Internal.cmake as a change of internals. Sure, everything is accessible to others since this file is installed, but I would expect nobody to use that specific variable other than with the macros in KDE4Macros.cmake. And since FindKDE4Internal and KDE4Macros go together, if the latter stops using KDE4_AUTOMOC_EXECUTABLE, the former should be free to remove the check. IMHO. Same for KDE4_SET/GET_TARGET_PROPERTY(), that's an internal macro and I think I didn't document it either. I think it can be removed. Perhaps there needs to be some policy to mark macros as internal or compatibility will be kept. For now nothing seems to be internal. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Thursday 08 May 2008, Alexander Neundorf wrote: Oh, and what about FindAutomoc4.cmake? Currently it only exists in kdesupport/akonadi/cmake/modules... This will of course also be in kdelibs then. I thought it could perhaps ship with automoc4 itself. That would then be the one and only true source for this file (instead of having copies in all the places that use cmake+automoc but not kdelibs) -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc4
On Wednesday 30 April 2008, Alexander Neundorf wrote: Von: Matthias Kretz [EMAIL PROTECTED] On Tuesday 29 April 2008, Alexander Neundorf wrote: Is there an easy way to enforce rerunning automoc ? Would it be possible to add a command line switch which does that ? Like e.g. deleting all generated moc files or something like that ? Alternatives: 1. add a new target (I'd like to avoid that because it would add a lot of I/O on a cmake run) 2. make it easy to run automoc4 manually Yes, something like automoc4 --clean or something like this which does that for the current dir and maybe all subdirs would be nice to have. How about the following: - automoc, when done, writes an empty file target_automoc.notclean - SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES target_automoc.notclean) - automoc will recreate all moc files if the target_automoc.notclean file is not present (else it will work as it does now) = after a make clean, running make which executes automoc will recreate all moc files. This would again need automoc to be called unconditionally (which I still believe would be good to do - and the touch can be done by automoc itself, which would be portable). -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: CMake dependency scanning for .moc files
On Thursday 17 April 2008, Matthias Kretz wrote:
run kde4automoc unconditionally for all targets
With a patch to kde4automoc.cpp it's not too bad. Please try the attached
patch. And if you think this is the way to go then let me know how to
unconditionally run automoc without that touch hack.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: automoc/kde4automoc.cpp
===
--- automoc/kde4automoc.cpp (revision 797272)
+++ automoc/kde4automoc.cpp (working copy)
@@ -38,7 +38,7 @@
bool run();
private:
-void generateMoc(const QString sourceFile, const QString mocFileName);
+bool generateMoc(const QString sourceFile, const QString mocFileName);
void waitForProcesses();
void usage(const QString );
void echoColor(const QString msg)
@@ -66,6 +66,7 @@
};
QQueueProcess processes;
bool failed;
+bool automocCppChanged;
};
void AutoMoc::usage(const QString path)
@@ -84,7 +85,8 @@
}
AutoMoc::AutoMoc()
-: verbose(!qgetenv(VERBOSE).isEmpty()), cerr(stderr), cout(stdout), failed(false)
+: verbose(!qgetenv(VERBOSE).isEmpty()), cerr(stderr), cout(stdout), failed(false),
+automocCppChanged(false)
{
const QByteArray colorEnv = qgetenv(COLOR);
cmakeEchoColorArgs -E cmake_echo_color QString(--switch=) + colorEnv --blue
@@ -256,7 +258,9 @@
end = notIncludedMocs.constEnd();
it = notIncludedMocs.constBegin();
for (; it != end; ++it) {
-generateMoc(it.key(), it.value());
+if (generateMoc(it.key(), it.value())) {
+automocCppChanged = true;
+}
outStream #include \ it.value() \\n;
}
}
@@ -272,7 +276,19 @@
}
outStream.flush();
-// source file that includes all remaining moc files
+if (!automocCppChanged) {
+// compare contents of the _automoc.cpp file
+outfile.open(QIODevice::ReadOnly | QIODevice::Text);
+const QByteArray oldContents = outfile.readAll();
+outfile.close();
+if (oldContents == automocSource) {
+// nothing changed: don't touch the _automoc.cpp file
+return true;
+}
+}
+// either the contents of the _automoc.cpp file or one of the mocs included by it have changed
+
+// source file that includes all remaining moc files (_automoc.cpp file)
outfile.open(QIODevice::WriteOnly | QIODevice::Text | QIODevice::Truncate);
outfile.write(automocSource);
outfile.close();
@@ -301,7 +317,7 @@
}
}
-void AutoMoc::generateMoc(const QString sourceFile, const QString mocFileName)
+bool AutoMoc::generateMoc(const QString sourceFile, const QString mocFileName)
{
//qDebug() Q_FUNC_INFO sourceFile mocFileName;
const QString mocFilePath = builddir + mocFileName;
@@ -332,13 +348,15 @@
args -o mocFilePath sourceFile;
//qDebug() executing: mocExe args;
mocProc-start(mocExe, args, QIODevice::NotOpen);
-if (mocProc-waitForStarted())
+if (mocProc-waitForStarted()) {
processes.enqueue(Process(mocProc, mocFilePath));
-else {
+return true;
+} else {
cerr kde4automoc: process for mocFilePath failed to start:
mocProc-errorString() endl;
failed = true;
delete mocProc;
}
}
+return false;
}
Index: modules/KDE4Macros.cmake
===
--- modules/KDE4Macros.cmake (revision 797272)
+++ modules/KDE4Macros.cmake (working copy)
@@ -226,7 +226,10 @@
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}
${QT_MOC_EXECUTABLE}
+ COMMAND touch ${_automoc_source}.files
DEPENDS ${${_SRCS}} ${_moc_headers} ${_automoc_source}.files ${_KDE4_AUTOMOC_EXECUTABLE_DEP}
+ COMMENT running automoc for ${_target_NAME}
+ VERBATIM
)
# the OBJECT_DEPENDS is only necessary when a new moc file has to be generated that is included in a source file
# problem: the whole target is recompiled when the automoc.cpp file is touched
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: CMake dependency scanning for .moc files
On Wednesday 16 April 2008, Alexander Neundorf wrote: On Wednesday 16 April 2008, Andreas Pakulat wrote: On 15.04.08 19:19:45, Alexander Neundorf wrote: On Monday 14 April 2008, Andreas Pakulat wrote: Hi, so today I found that there are actually problems with cmake 2.6 and dependency scanning. a) after changing an installed header the .moc files for headers that include the updated header are not re-generated which might cause problems when you do ABI changes (like removing a method) on the installed header (linking errors) b) removing a .moc file from the builddir doesn't produce a re-moc, cmake just tells gcc to compile the non-existing .moc-file. I'm actually not sure wether either of the two ever worked, but IMHO at least the second one should work. This is was tested on CMake 2.6 and 2.4.7. And it works with 2.4.7 but doesn't with 2.6 ? It doesn't work with either of the two. Ok, so it's at least no cmake 2.6 problem, but automoc. This is a moc file handled via automoc, right ? Yes. The only way to get cmake to re-generate the .moc file is to touch the header from which its generated or remove the subdir in the builddir that contains the .moc file. In the resulting Makefiles there are no dependencies on the actual moc files. The upside of this is that changing a moc-include doesn't need a cmake rerun (that includes adding Q_OBJECT to a class - before kde4automoc you had to rerun cmake then). Even if the Makefile doesn't have a dep on the moc files, if kde4automoc is run it will compare the timestamps of the moc file against it's source file (header or cpp), that's why touching the .h file works. IIUC you want to look at the timestamps of all the headers that are directly or indirectly included from the file that is moced. AFAIK not even cmake generated Makefiles do that for compilation (I imagine that would be rather expensive information). If they do I'd like to know how to get at that dependency info to reuse it for kde4automoc. But really, I think that if the installed headers change in a binary incompatible way the only safe thing you can do is a make clean. Conclusion: I think everything works as it should. At least from the problem description above. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: OpenGL vs. Qt4 OpenGL
On Friday 14 December 2007, Andreas Pakulat wrote:
On 13.12.07 17:53:49, Allen Winter wrote:
kpat links against ${QT_QTOPENGL_LIBRARY}, which points to
qt-copy/lib/libQtOpenGL.so
so this is why I'm confused. I do have 2 separate OpenGL builds
available.
should we permit stuff to build against QT_QTOPENGL?
so far, the only instance I've seen of this is in kpat
I'm not into that stuff that much, but I think things like kwin that
want to render directly onto the screen with OpenGL need to link only
against libGL, not against libQtOpenGL.
If an app however only wants to display an OpenGL scene inside a QWidget
then it primarly needs QtOpenGL. (the libGL is automatically pulled in
through the deps).
Just a small correction...
there are basically three cases for Qt apps with GL:
a) using only libGL (e.g. kwin)
b) using only libQtOpenGL (e.g. an application that just wants QPainter to use
OpenGL internally)
c) using both libGL and libQtOpenGL (e.g. an app that uses OpenGL calls for a
QGLWidget)
a) needs ${OPENGL_gl_LIBRARY}
b) needs ${QT_QTOPENGL_LIBRARY}
c) needs ${QT_QTOPENGL_LIBRARY} ${OPENGL_gl_LIBRARY}
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Automoc for .hxx, .hpp, .H files
On Tuesday 11 December 2007, Loïc Corbasson wrote: Hi List, I'm working on a KDE-ization of SpeedCrunch (a handy calculator program) and discovered that Automoc doesn't like its .hxx headers. As it scans .cpp, .cc, .cxx and .C files for moc includes, I think that being able to use .hh, .hxx and .H files in addition to .h for the headers would be quite logical. I prepared a patch for kdelibs/cmake/automoc/kde4automoc.cpp and attached it to this mail. Should I commit? Looks good. If you tested a clean compilation of at least one module (kdelibs/kdebase preferred) we can be extra sure nothing breaks. But at least from the patch I don't expect any regressions. Matthias. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
automoc support for private headers
Hi,
I'd like to make kde4automoc look for Q_OBJECT macros in private headers
automatically. This is very convenient as it just makes everything work
automatically (I was putting Q_OBJECT macros in _p.h files in
playground/multimedia/phonon/mixer and expected the automoc to work, but it
didn't).
I have been using this patch for a week or so now and seen no regressions. Ok
to commit?
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: automoc/kde4automoc.cpp
===
--- automoc/kde4automoc.cpp (revision 716231)
+++ automoc/kde4automoc.cpp (working copy)
@@ -168,6 +168,18 @@
notIncludedMocs.insert(headername, currentMoc);
}
}
+const QString privateHeaderName = absPath + basename + _p.h;
+if (QFile::exists(privateHeaderName) !includedMocs.contains(privateHeaderName)
+!notIncludedMocs.contains(privateHeaderName)) {
+const QString currentMoc = moc_ + basename + _p.cpp;
+QFile header(privateHeaderName);
+header.open(QIODevice::ReadOnly);
+const QByteArray contents = header.readAll();
+if (qObjectRegExp.indexIn(QString::fromUtf8(contents)) = 0) {
+//qDebug() header contains Q_OBJECT macro;
+notIncludedMocs.insert(privateHeaderName, currentMoc);
+}
+}
} else {
do { // call this for every moc include in the file
const QString currentMoc = mocIncludeRegExp.cap(1);
Index: modules/KDE4Macros.cmake
===
--- modules/KDE4Macros.cmake (revision 716231)
+++ modules/KDE4Macros.cmake (working copy)
@@ -207,6 +207,10 @@
if(EXISTS ${_header})
list(APPEND _moc_headers ${_header})
endif(EXISTS ${_header})
+set(_pheader ${_abs_path}/${_basename}_p.h)
+if(EXISTS ${_pheader})
+ list(APPEND _moc_headers ${_pheader})
+endif(EXISTS ${_pheader})
list(APPEND _moc_files ${_abs_current_FILE})
endif(_suffix STREQUAL .cpp OR _suffix STREQUAL .cc OR _suffix STREQUAL .cxx OR _suffix STREQUAL .C)
endif(NOT _generated AND NOT _skip)
pgpOtROovSHxS.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc support for private headers
On Monday 24 September 2007, Thiago Macieira wrote: Em Monday 24 September 2007 13:19:50 Matthias Kretz escreveu: I'd like to make kde4automoc look for Q_OBJECT macros in private headers automatically. This is very convenient as it just makes everything work automatically (I was putting Q_OBJECT macros in _p.h files in playground/multimedia/phonon/mixer and expected the automoc to work, but it didn't). I have been using this patch for a week or so now and seen no regressions. Ok to commit? Does this still allow us to #include basename_p.moc ? Yes, because kde4automoc keeps a list of all #included mocs and all mocs it is going to compile on its own. If a file appears in both lists it gets removed from the latter. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgph1CjzP7riL.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc error
Fixed now. It was an error in kde4automoc. It did not wait for the moc processes that were creating the moc files for the _automoc.cpp file to finish. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpMKAUoAMDMq.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc error
On Friday 20 July 2007, David Faure wrote: updated kdelibs, ran make -j5, got /d/kde/build/4/kdelibs/kstyles/oxygen/picturepusher/oxygenPP_automoc.cpp:2: 23: error: moc_opp.cpp: No such file or directory I don't understand how this could happen at all. oxygenPP_automoc.cpp is a generated file, so make will call the custom_command to generate the file and wait until it's done before compiling it. But when kde4automoc is finished generating the oxygenPP_automoc.cpp file the moc_opp.cpp file is already created (except if moc failed). -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpZIEEzaypo1.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Unexpected behaviour of kde4automoc
On Friday 13 July 2007, Jarosław Staniek wrote: On windows (msvc) kde4automoc executes moc in new window for a quarter of second or so (closes as soon as moc finishes). Have anybody encountered the same for kdelibs updated yesterday? Do you need to add WIN32 to add_executable in kdelibs/cmake/automoc/CMakeLists.txt? -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpBZCgHGxwOD.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Unexpected behaviour of kde4automoc
On Friday 13 July 2007, Ralf Habacker wrote: Christian Ehrlicher schrieb: Jarosław Staniek schrieb: Hello, On windows (msvc) kde4automoc executes moc in new window for a quarter of second or so (closes as soon as moc finishes). Have anybody encountered the same for kdelibs updated yesterday? moc is a console app - QProcess spawns a new moc process and the new window appears. Don't know how to tell QProcess to not open the console. Maybe the moc output should be redirected to the current console window (at least for 'make VERBOSE=1') Maybe QProcess::detached ? Ah, now I understand - I thought it was kde4automoc that was doing wrong... cmake -E cmake_echo_color ... is started with QProcess::startDetached. The moc processes are started with QProcess::start. The problem with starting moc detached is that kde4automoc may not finish before the moc processes are done. This is how moc is executed: QProcess *mocProc = new QProcess; mocProc-setProcessChannelMode(QProcess::ForwardedChannels); mocProc-start(mocExe, args, QIODevice::NotOpen); -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpxI0KodI1sW.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: automoc v2
On Tuesday 10 July 2007, Alexander Neundorf wrote: On Friday 06 July 2007 18:51, Matthias Kretz wrote: I replaced kde4automoc.cmake with a C++/QtCore based program that can run more efficient. ...which is good, but this doesn't help cmake time (but build time, which is also good). Yes, build time got noticably slower and would have gotten even slower with the features I introduced to the C++ base automoc. run make - everything compiles and links fine (without mentioning the header in KDE4_MOC_HEADERS either since the new automoc looks at all corresponding header files from the .cpp files by itself) This means if there's a header which needs to be mocced but this isn't done via including the moc file this will be detected automatically ? Yes. As long as automoc somehow can guess that the header belongs to the target. Which is almost impossible to _know_ without parsing C++. No, it doesn't. Because I made the _automoc.cpp depend on all .cpp files that are passed as sources plus all corresponding existing .h files. If Existing at cmake time... This isn't really good, so we still have some part of the the problem we had with the old automoc. I think this wasn't the case for the first version of the new automoc I sent, there a custom target for every target was used. So there was a reason that it was a custom target instead of a custom command which creates a file. Even if it's slower, it will be correct, so it probably needs to be a custom target. Yes, the custom target simply had a dependency on the main target. Does cmake figure out the dependencies for the target at make time? Because otherwise renaming a header file would have the same effect only that it's the .cpp which included the header file before would now be named as the offender. There are two downsides of using a custom target: a) a lot of I/O at cmake time b) the automoc target is not remade on /fast The current setup still has one dependency problem though: make doesn't know that the .moc includes in the .cpp files are generated by creating the _automoc.cpp file and therefore does not wait for kde4automoc to finish before compiling the other sources. By making the automoc a custom target that can be fixed because then all of the target depends on the automoc. Is there another way? ADD_CUSTOM_COMMAND(TARGET target PRE_BUILD ...) doesn't work :-( For the mocing headers which are not included via automoc... I understand correctly that this is currently done for headers where a corresponding source file is listed as source ? I think doing this is not a good idea. While this will work in most cases, it will not work if there are headers which have no corresponding .cpp file and which are not automoced. While this is probably a rare case, it still will not work and will be hard to debug (it works for most headers,but some headers are not moced, what am I doing wrong ?). I suggest to parse only files for include ...moc... or Q_OBJECT which have been listed as source file, i.e. if there are headers which are not automoced then they have to be listed as sources. This will make it easier to understand how moc is handled. Then we also don't need KDE4_MOC_HEADERS() and KDE4_GET_CUSTOM_TARGET_PROPERTY(). I still think adding headers to the list of sources of a target is awkward and not at all self-explanatory. Adding headers to a macro that has moc in the name says so much more. We could switch back to not scanning header files automatically but I think it only makes it harder to get right then. Ok, I thought I could make the automoc target depend on the .files file. But all those are touched when cmake is run. When using FILE(WRITE ...) the file is unconditionally written. If you use CONFIGURE_FILE(), it is only written if it has actually changed. Thanks. Changed it now. I'm about to change the dependency back to a dep on srcdir/CMakeLists.txt Hmm, this sounds strange. Somebody might do include(SomeFile.cmake) which holds the variable settings and then this dependency doesn't work as exptected. Yeah, fixed with the change above. A more generic note: I wanted to keep the buildsystem for KDE4 easy to understand with generic cmake knowledge. A lot of things have been done since then and not everything is as straight forward as it was in the beginning, e.g. RPATH and other things. Now we moved automoc into an external tool (kde4automoc.cmake), and now we are about to move a part of it into an executable which is build as part of kdelibs. I also already thought about turning it somehow into a binary. It should also be possible to write a cmake command which can be loaded as plugin by cmake itself. Buth then again I thought this makes the build to hard to understand... On IRC I heard that kde4automoc.cmake was complete magic to somebody. OTOH I think all KDE developers will be able to understand the code of kde4automoc with little effort (the hardest part
Re: *** GMX Spamverdacht *** automoc v2
On Monday 09 July 2007, Andreas Pakulat wrote: On 07.07.07 00:51:38, Matthias Kretz wrote: Hi, attached you'll find the next generation of automoc I replaced kde4automoc.cmake with a C++/QtCore based program that can run more efficient. I've got one question: Could it be that a change in any CMakeLists.txt triggers a full rerun of the automoc stuff and thus a full relinkage of the whole module? Yes, the _automoc.cpp has a dependency on the CMakeLists.txt of the sourcedir of its target. This can probably be changed to a dependency on the _automoc.cpp.files file now. At least thats what I see here at the moment. I changed kdelibs/kate/CMakeLists.txt and now it relinks and regenerates all foo_automoc.cpp. All == all of kdelibs? I have not seen such behaviour... -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgp1ErUzQHvfS.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: *** GMX Spamverdacht *** automoc v2
On Monday 09 July 2007, Andreas Pakulat wrote: On 09.07.07 21:53:48, Matthias Kretz wrote: On Monday 09 July 2007, Andreas Pakulat wrote: On 07.07.07 00:51:38, Matthias Kretz wrote: At least thats what I see here at the moment. I changed kdelibs/kate/CMakeLists.txt and now it relinks and regenerates all foo_automoc.cpp. All == all of kdelibs? I have not seen such behaviour... Yes, all targets in kdelibs are relinked. Ok, I thought I could make the automoc target depend on the .files file. But all those are touched when cmake is run. I'm about to change the dependency back to a dep on srcdir/CMakeLists.txt -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpAUIMjrJyru.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
automoc v2
Hi,
attached you'll find the next generation of automoc
I replaced kde4automoc.cmake with a C++/QtCore based program that can run more
efficient.
Instead of creating a targetname.automoc file that is added to the target I
create a targetname_automoc.cpp file now that is compiled and linked into
the target. This file #includes all moc files that are not included by other
source files. This way the automoc can, at make-time, decide what mocs need
to be compiled explicitly and linked into the target.
E.g. the following is possible now:
foo.h:
class A : public QObject
{
Q_OBJECT
...
};
foo.cpp does not #include foo.moc
run make - everything compiles and links fine (without mentioning the header
in KDE4_MOC_HEADERS either since the new automoc looks at all corresponding
header files from the .cpp files by itself)
now change foo.cpp to #include foo.moc
running make now will just work, even with the /fast target.
Next change I did was to create a targetname_automoc.cpp.files file to pass
the moc includes and the source files that belong to the target to the
automoc. I could have kept it on the command line but I got a report that the
command line was already too long for Windows' cmd.exe.
Implementation details:
- The messages of the automoc are written using cmake -E cmake_echo_color, so
the automoc correctly colorizes its messages now.
- The moc QProcesses are started in parallel (up to 10).
Please test and let me know if you have any problems (you might have to remove
some explicit QT4_WRAP_CPP calls from CMakeLists.txt now). I'd like to commit
soon, as this is supposed to fix compilation on Windows again...
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: automoc/kde4automoc.cpp
===
--- automoc/kde4automoc.cpp (revision 0)
+++ automoc/kde4automoc.cpp (revision 0)
@@ -0,0 +1,270 @@
+/* This file is part of the KDE project
+Copyright (C) 2007 Matthias Kretz [EMAIL PROTECTED]
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 2
+as published by the Free Software Foundation.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301, USA.
+
+*/
+
+#include QtCore/QCoreApplication
+#include QtCore/QDateTime
+#include QtCore/QFile
+#include QtCore/QFileInfo
+#include QtCore/QHash
+#include QtCore/QProcess
+#include QtCore/QQueue
+#include QtCore/QRegExp
+#include QtCore/QStringList
+#include QtCore/QTextStream
+#include QtCore/QtDebug
+#include cstdlib
+
+class AutoMoc
+{
+public:
+AutoMoc();
+~AutoMoc();
+void run();
+
+private:
+void generateMoc(const QString sourceFile, const QString mocFileName);
+void usage(const QString );
+void echoColor(const QString msg)
+{
+QProcess cmakeEcho;
+cmakeEcho.setProcessChannelMode(QProcess::ForwardedChannels);
+QStringList args(cmakeEchoColorArgs);
+args msg;
+cmakeEcho.startDetached(cmake, args);
+}
+
+QString bindir;
+QString mocExe;
+QStringList mocIncludes;
+QStringList cmakeEchoColorArgs;
+const bool verbose;
+QTextStream cerr;
+QTextStream cout;
+QQueueQProcess * mocProcesses;
+};
+
+void AutoMoc::usage(const QString path)
+{
+cout usage: path outfile srcdir bindir moc executable endl;
+::exit(EXIT_FAILURE);
+}
+
+int main(int argc, char **argv)
+{
+QCoreApplication app(argc, argv);
+AutoMoc().run();
+return 0;
+}
+
+AutoMoc::AutoMoc()
+: verbose(!QByteArray(getenv(VERBOSE)).isEmpty()), cerr(stderr), cout(stdout)
+{
+const QByteArray colorEnv = getenv(COLOR);
+cmakeEchoColorArgs -E cmake_echo_color QString(--switch=) + colorEnv --blue
+ --bold;
+}
+
+void AutoMoc::run()
+{
+const QStringList args = QCoreApplication::arguments();
+Q_ASSERT(args.size() 0);
+if (args.size() 4) {
+usage(args[0]);
+}
+QFile outfile(args[1]);
+const QFileInfo outfileInfo(outfile);
+
+QString srcdir(args[2]);
+if (!srcdir.endsWith('/')) {
+srcdir += '/';
+}
+bindir = args[3];
+if (!bindir.endsWith('/')) {
+bindir += '/';
+}
+mocExe = args[4];
+
+QFile dotFiles(args[1] + .files);
+dotFiles.open(QIODevice::ReadOnly
Re: Fixing output of new automoc macro
On Wednesday 04 July 2007, Andreas Pakulat wrote: a) its not coloured so you can't easily ignore it. Normally in a make run standard-coloured lines indicate errors or warnings so this is confusing at first sight. It seems this is some CMake-Source-Internal stuff that creates the coloring for things like Generating Foobar. Generating targetname.automoc is colored in blue The messages written by kde4automoc.cmake cannot be colored without patching cmake itself (AFAICS). b) Its too long. It contains the full absolute path of the header and the moc file. IMHO it should be just the filename or if possible the relative path of the .h to the CMakeLists.txt (i.e. for things in kdeui it would be widget/foobar.h) I like to see all the information there. If it's a relative path it could be in the src or build dir. And if it doesn't show what file it's creating the moc from you don't know whether it's creating it from the .h or the .cpp file. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpc7YpIZuc4e.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fixing output of new automoc macro
On Wednesday 04 July 2007, Andreas Pakulat wrote: The idea is ok, but does this also work with make VERBOSE=1? Because thats the standard cmake way (AFAIK) of getting verbose output. Yes, that's what I showed in my previous email. Is there any difference between 'VERBOSE=1 make' and 'make VERBOSE=1'? -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgp7n2Dx8muwC.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make KDE4_AUTOMOC compatible to qmake
On Friday 29 June 2007, Alexander Neundorf wrote:
On Thursday 28 June 2007 11:20, Matthias Kretz wrote:
after that it seems to work, at least my stuff. Here's an error I didn't
look into:
Scanning dependencies of target globalcleanuptest
[ 8%] Building CXX object
kdecore/tests/CMakeFiles/globalcleanuptest.dir/globalcleanuptest.o
g++: libs/kdecore/tests: No such file or directory
command line:1:1: warning: KDESRCDIR redefined
command line:1:1: warning: this is the location of the previous
definition make[2]: ***
[kdecore/tests/CMakeFiles/globalcleanuptest.dir/globalcleanuptest.o]
Error 1 make[1]: *** [kdecore/tests/CMakeFiles/globalcleanuptest.dir/all]
Error 2
I renamed my src/kdelibs dir to src/kde\ libs and obj/kdelibs to obj/kde\
libs
make VERBOSE=1 would be help more here.
Yes, in the meantime I fixed it in trunk already.
Last night it occurred to me that adding a custom target is very IO
expensive since it needs to create the whole ${target_name}.dir directory
structure plus all the files contained in it. So I tried to get rid of
the custom automoc target again and instead use a custom command. Patch
against trunk (svn di -x -w) attached.
So instead of creating a target you create a custom command which produces
the mark file which is added as source to the target which will not be
compiled because it has an unknown suffix.
Sounds good at a first glance.
Exactly. And I made the mark file depend on all relevant .cpp files and
their .h counterparts if they exist. That way touching the .h file will run
the automoc.
timings for kdelibs with the new patch:
without cache: 37.97s user 10.99s system 45% cpu 1:46.53 total
withcache: 14.89s user 2.13s system 24% cpu 1:09.05 total
CPU usage seems higher, it still seems faster though which must be from
the reduced IO.
So this saves 1 to 2 from 39 s ?
Can you reproduce this or can this also be random noise ?
It is reproduceably faster than the older automoc patches.
Compared to current trunk it's still slower (my timing above must've been a
lucky run):
trunk : total time = 1:11.50s +/- 2.33s (10 runs)
patched: total time = 1:19.02s +/- 5.82s (19 runs)
Also, looking at the speed of the kde4automoc script is not very
convincing. :-( I think the potential of this change is to make the automoc
pick up changes without having to rerun cmake, but not to increase the speed.
Regarding picking up changes I had another idea: The .automoc file could be
used to #include all the moc files that are not #included in any .cpp file of
the target. Then the target would compile and link that file. That way the
automoc, that is run at make time, can dynamically add and remove files
to/from the target.
As a developer you'd simply add a Q_OBJECT macro to a .h file and magically
the moc would be run, compiled and linked in without having to change
CMakeLists.txt and without having to rerun cmake.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
pgpMLTca0wOlt.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make KDE4_AUTOMOC compatible to qmake
On Wednesday 27 June 2007, Alexander Neundorf wrote:
Could you maybe measure cmake times with the old and the new one with cold
and warm caches ?
Measuring is almost impossible. Using
time cmake
I get +/- 50% on total time. But here are the numbers:
old automoc:
without cache: 39.47s user 12.53s system 36% cpu 2:22.32 total
withcache: 16.59s user 2.62s system 26% cpu 1:13.69 total
new automoc as from Alex's patch:
without cache: 38.78s user 12.06s system 32% cpu 2:38.27 total
withcache: 16.15s user 3.01s system 18% cpu 1:42.67 total
reworked patch:
without cache: 39.01s user 11.80s system 34% cpu 2:26.86 total
withcache: 16.03s user 2.75s system 20% cpu 1:32.07 total
without cache means:
% rm CMakeCache.txt
% time cmake -DCMAK... ../../src/kdelibs
with cache:
% time cmake ./
Anyway, I changed quite a bit:
1. don't create _automoc.files files anymore; instead pass all the variables
on the command line to kde4automoc.cmake. I did this in order to save on IO
at cmake time. (Optimizing cmake performance is guesswork or do you have any
way to gather better data?)
2. I added KDE4_MOC_HEADERS that takes the target and a list of header files.
The headers are then moc'ed and the resulting moc_foo.cpp file is added to
the list of source files of the given target.
3. If kde4automoc.cmake is given a header file then it will simply create a
moc_foo.cpp file from it (might result in an empty file).
4. kde4automoc.cmake now recreates the moc file if only the header was changed
5. tried unsuccessfully to make kde4automoc.cmake show Automoc: Generating
${_moc} from ${_moc_source} in color
6. the _automoc.mark file is now only used for a timestamp, the variables that
were written to it and later read from it again are now used directly
7. If the .cpp file contains #include filename.moc and ^[ \t]*Q_OBJECT
then the moc file is created from the .cpp file
So far I tested it with kdelibs only.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: KDE4Macros.cmake
===
--- KDE4Macros.cmake (revision 680441)
+++ KDE4Macros.cmake (working copy)
@@ -5,6 +5,11 @@
# KDE4_ADD_UI3_FILES
# KDE4_ADD_KCFG_FILES
# KDE4_AUTOMOC
+# KDE4_SET_CUSTOM_TARGET_PROPERTY
+# KDE4_GET_CUSTOM_TARGET_PROPERTY
+# KDE4_MOC_HEADERS
+# KDE4_APPEND_MOC_FILES
+# KDE4_HANDLE_AUTOMOC
# KDE4_INSTALL_LIBTOOL_FILE
# KDE4_CREATE_FINAL_FILES
# KDE4_ADD_KDEINIT_EXECUTABLE
@@ -22,6 +27,7 @@
# Copyright (c) 2006, 2007, Alexander Neundorf, [EMAIL PROTECTED]
# Copyright (c) 2006, 2007, Laurent Montel, [EMAIL PROTECTED]
+# Copyright (c) 2007 Matthias Kretz [EMAIL PROTECTED]
#
# Redistribution and use is allowed according to the terms of the BSD license.
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
@@ -145,77 +151,79 @@
endforeach (_current_FILE)
endmacro (KDE4_ADD_UI3_FILES)
-
+# keep it here until it is removed everywhere
macro (KDE4_AUTOMOC)
- qt4_get_moc_inc_dirs(_moc_INCS)
+endmacro (KDE4_AUTOMOC)
- # iterate over all files
- foreach (_current_FILE ${ARGN})
+macro (KDE4_SET_CUSTOM_TARGET_PROPERTY _target_name _property_name _property)
+ string(REPLACE [/ ] _ _dir ${CMAKE_CURRENT_SOURCE_DIR})
+ set(_kde4_${_dir}_${_target_name}_${_property_name} ${_property})
+endmacro (KDE4_SET_CUSTOM_TARGET_PROPERTY)
- get_filename_component(_abs_FILE ${_current_FILE} ABSOLUTE)
- # if SKIP_AUTOMOC is set to true, we will not handle this file here.
- # here. this is required to make bouic work correctly:
- # we need to add generated .cpp files to the sources (to compile them),
- # but we cannot let automoc handle them, as the .cpp files don't exist yet when
- # cmake is run for the very first time on them - however the .cpp files might
- # exist at a later run. at that time we need to skip them, so that we don't add two
- # different rules for the same moc file
- get_source_file_property(_skip ${_abs_FILE} SKIP_AUTOMOC)
+macro (KDE4_GET_CUSTOM_TARGET_PROPERTY _var _target_name _property_name)
+ string(REPLACE [/ ] _ _dir ${CMAKE_CURRENT_SOURCE_DIR})
+ set(${_var} ${_kde4_${_dir}_${_target_name}_${_property_name}})
+endmacro (KDE4_GET_CUSTOM_TARGET_PROPERTY)
- # if the file exists and should not be skipped read it completely into memory
- # and grep for all include foo.moc lines
- # for each found moc file generate a custom_target and collect
- # the generated moc files in a list which will be set as a source files property
- # and later be queried in kde4_add_library/executable/plugin()
- if (EXISTS ${_abs_FILE} AND NOT _skip)
- set(_moc_FILES_PROPERTY)
+macro (KDE4_MOC_HEADERS _target_NAME)
+ set (_headers_to_moc)
+ foreach (_current_FILE ${ARGN})
+ get_filename_component(_suffix
Re: make KDE4_AUTOMOC compatible to qmake
Is it ok if I commit the KDE4Macros.cmake change to make the delayed automoc work? Or do you want to do it? Any showstoppers with it? I just committed my patch to kde4automoc.cmake to make the moc include qmake compatible there... -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpxMfe2QzlUC.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
fatal error if KDE compiles with hidden visibility but Q_DECL_EXPORT is defined to nothing
Hi,
as I just got my second report that phonon doesn't link I thought I'd better
implement a check that errors out if Qt has been compiled without visibility
support but KDE is compiled with default hidden visibility.
This is necessary for
1. phonon which uses Q_DECL_EXPORT as export macro
2. all plugins that export their entry symbols using Q_DECL_EXPORT or any
other macro that uses Q_DECL_EXPORT
Ok, to commit the attached patch?
PS: please CC me on replys
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: FindKDE4Internal.cmake
===
--- FindKDE4Internal.cmake (revision 677006)
+++ FindKDE4Internal.cmake (working copy)
@@ -753,7 +753,22 @@
if (__KDE_HAVE_GCC_VISIBILITY AND GCC_IS_NEWER_THAN_4_1 AND NOT _GCC_COMPILED_WITH_BAD_ALLOCATOR)
set (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -fvisibility=hidden)
set (KDE4_C_FLAGS -fvisibility=hidden)
+ # check that Qt defines Q_DECL_EXPORT as __attribute__ ((visibility(default)))
+ # if it doesn't and KDE compiles with hidden default visibiltiy plugins will break
+ set(_source #include QtCore/QtGlobal\n int main()\n {\n #ifdef QT_VISIBILITY_AVAILABLE \n return 0;\n #else \n return 1; \n #endif \n }\n)
+ set(_source_file ${CMAKE_BINARY_DIR}/CMakeTmp/check_qt_visibility.cpp)
+ file(WRITE ${_source_file} ${_source})
+ set(_include_dirs -DINCLUDE_DIRECTORIES:STRING=${QT_INCLUDES})
+ try_run(_run_result _compile_result ${CMAKE_BINARY_DIR} ${_source_file} CMAKE_FLAGS ${_include_dirs})
+
+ if(NOT _compile_result)
+ message(FATAL_ERROR Could not compile simple test program ${_source})
+ endif(NOT _compile_result)
+ if(_run_result)
+ message(FATAL_ERROR Qt compiled without support for -fvisibility=hidden)
+ endif(_run_result)
+
if (GCC_IS_NEWER_THAN_4_2)
set (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -fvisibility-inlines-hidden)
endif (GCC_IS_NEWER_THAN_4_2)
pgp55E3bXBMZz.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make KDE4_AUTOMOC compatible to qmake
On Monday 18 June 2007, Alexander Neundorf wrote:
On Saturday 16 June 2007 06:50, you wrote:
On Tuesday 12 June 2007, Alexander Neundorf wrote:
Hi,
On Saturday 09 June 2007 05:20, Matthias Kretz wrote:
On Saturday 09 June 2007, Alexander Neundorf wrote:
On Friday 08 June 2007 05:07, Matthias Kretz wrote:
On Friday 08 June 2007, Alexander Neundorf wrote:
Using OBJECT_DEPENDS works more or less, but not 100%.
:( Is this a bug in cmake or is it some corner case that
add_library/add_executable works around?
IOW we have to stay with a non-source-file extension.
How about the attached patch? It creates a new top-level target
that depends on all moc custom commands and the
library/executable target then depends on that moc target.
I tried it with a clean kdelibs build and it created _all_ moc
files before it started any compile job. I'm not sure why
cmake/make does that but it's not really wrong either.
A variation of the patch could be to check for .cpp files in
_automoc_FILES and only then add this additional top-level
target. Else do the same as before.
I still have a patch here which moves the automoc test from
cmake-time to build time (i.e. faster cmake run)
This and your patch might fit together.
I have to get it up-to-date and then we can see whether they work
together. Please don't commit before.
OK, then I'll revert my local moc include changes in phonon -
otherwise I can't work on it anymore... The reason why I'd like to
have it working soon is that Trolltech wants to be able to compile
phonon using qmake (makes it easier for them to work on Windows and
MacOS).
attached you can find a modified KDE4Macros.cmake.
It creates for every target a automoc target, which executes an
external cmake script (kde4automoc.cmake), which does the actual
parsing. It seems to work here for me for kdelibs.
In kde4automoc.cmake it should be easy to also search for moc_*.cpp
files.
Yep. That was easy. :-) Patch attached.
Please give it a try and see how it works.
So far it's been working great. I especially like that I don't have to
Good to hear :-)
So you didn't have any problems ?
I hit a problem yesterday in kdebase. There a kcfgc file was compiled into
prefs.cpp. The target that was using the prefs.cpp file with the config
compiler cmake macro build fine, but there was another target that simply
specified prefs.cpp for its sources. I changed it to
${CMAKE_CURRENT_BINARY_DIR}/prefs.cpp and then it worked. Apparently this
worked with the old automoc, but I'm not sure why...
rerun cmake when something automoc related changes and the CMakeLists.txt
files don't change (e.g. if you forgot to #include the moc file). There
are many STATUS messages, but I guess you'll comment those out before
committing to trunk?
I can do that.
I thought it would be nice if you see what's going on, but it#s probably a
bit much.
Perhaps the generating message could be kept.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
pgpmurpQMux5x.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make KDE4_AUTOMOC compatible to qmake
On Monday 18 June 2007, Alexander Neundorf wrote: So you didn't have any problems ? See kdepim/kresources/groupdav/CMakeLists.txt lines 17 and 48. It defines two different targets with the same target name. The same on lines 31 and 63. This results in the _automoc.files file to be overwritten and the moc files for the first target are not generated. Is this a bug in the CMakeLists.txt? -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpiOCC87vXhO.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make KDE4_AUTOMOC compatible to qmake
On Tuesday 12 June 2007, Alexander Neundorf wrote:
Hi,
On Saturday 09 June 2007 05:20, Matthias Kretz wrote:
On Saturday 09 June 2007, Alexander Neundorf wrote:
On Friday 08 June 2007 05:07, Matthias Kretz wrote:
On Friday 08 June 2007, Alexander Neundorf wrote:
Using OBJECT_DEPENDS works more or less, but not 100%.
:( Is this a bug in cmake or is it some corner case that
add_library/add_executable works around?
IOW we have to stay with a non-source-file extension.
How about the attached patch? It creates a new top-level target that
depends on all moc custom commands and the library/executable target
then depends on that moc target.
I tried it with a clean kdelibs build and it created _all_ moc files
before it started any compile job. I'm not sure why cmake/make does
that but it's not really wrong either.
A variation of the patch could be to check for .cpp files in
_automoc_FILES and only then add this additional top-level target.
Else do the same as before.
I still have a patch here which moves the automoc test from cmake-time
to build time (i.e. faster cmake run)
This and your patch might fit together.
I have to get it up-to-date and then we can see whether they work
together. Please don't commit before.
OK, then I'll revert my local moc include changes in phonon - otherwise I
can't work on it anymore... The reason why I'd like to have it working
soon is that Trolltech wants to be able to compile phonon using qmake
(makes it easier for them to work on Windows and MacOS).
attached you can find a modified KDE4Macros.cmake.
It creates for every target a automoc target, which executes an external
cmake script (kde4automoc.cmake), which does the actual parsing.
It seems to work here for me for kdelibs.
In kde4automoc.cmake it should be easy to also search for moc_*.cpp files.
Yep. That was easy. :-) Patch attached.
Please give it a try and see how it works.
So far it's been working great. I especially like that I don't have to rerun
cmake when something automoc related changes and the CMakeLists.txt files
don't change (e.g. if you forgot to #include the moc file). There are many
STATUS messages, but I guess you'll comment those out before committing to
trunk?
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: kde4automoc.cmake
===
--- kde4automoc.cmake (revision 675396)
+++ kde4automoc.cmake (working copy)
@@ -18,23 +18,28 @@
set(_mocs_PER_FILE)
- string(REGEX MATCHALL #include +[^ ]+\\.moc[\] _match ${_contents})
+ string(REGEX MATCHALL #include +([\]moc_[^ ]+\\.cpp|[^ ]+\\.moc)[\] _match ${_contents})
if (_match)
foreach (_current_MOC_INC ${_match})
string(REGEX MATCH [^ \]+\\.moc _current_MOC ${_current_MOC_INC})
+if(_current_MOC)
+ get_filename_component(_basename ${_current_MOC} NAME_WE)
+else(_current_MOC)
+ string(REGEX MATCH moc_[^ \]+\\.cpp _current_MOC ${_current_MOC_INC})
+ get_filename_component(_basename ${_current_MOC} NAME_WE)
+ string(REPLACE moc_ _basename ${_basename})
+endif(_current_MOC)
-get_filename_component(_basename ${_current_MOC} NAME_WE)
set(_header ${_abs_PATH}/${_basename}.h)
set(_moc${KDE4_CURRENT_BINARY_DIR}/${_current_MOC})
+if (NOT EXISTS ${_header})
+ message(FATAL_ERROR In the file \${_filename}\ the moc file \${_current_MOC}\ is included, but \${_header}\ doesn't exist.)
+endif (NOT EXISTS ${_header})
+
list(APPEND _mocs_PER_FILE ${_basename})
file(APPEND ${_moc_mark_FILE} set( ${_basename}_MOC ${_moc})\n)
file(APPEND ${_moc_mark_FILE} set( ${_basename}_HEADER ${_header})\n)
-
-if (NOT EXISTS ${_abs_PATH}/${_basename}.h)
- message(FATAL_ERROR In the file \${_filename}\ the moc file \${_current_MOC}\ is included, but \${_abs_PATH}/${_basename}.h\ doesn't exist.)
-endif (NOT EXISTS ${_abs_PATH}/${_basename}.h)
-
endforeach (_current_MOC_INC)
endif (_match)
file(APPEND ${_moc_mark_FILE} set(mocs ${_mocs_PER_FILE})\n)
pgpbqwEuaibgW.pgp
Description: PGP signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make KDE4_AUTOMOC compatible to qmake
On Friday 08 June 2007, Thiago Macieira wrote: Alexander Neundorf said: IOW we have to stay with a non-source-file extension. Yep: *.moc for anything #included (this includes moc_*.moc, if needed) moc_*.cpp for anything that isn't #included (but has a Q_OBJECT nonetheless) But KDE4_AUTOMOC will not run the moc unless you include a file ending in .moc. QT4_GENERATE_MOC can be used to explicitly create a moc file from a header file, though it also uses OBJECT_DEPENDS (why is it allowed here and not in KDE4_AUTOMOC?). QT4_AUTOMOC also uses OBJECT_DEPENDS... -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgp4TuXz6XuaV.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: make KDE4_AUTOMOC compatible to qmake
Hi,
I updated the patch so that it now adds a dependency on the moc generated file
and does not add the moc files in the add_library/add_executable calls. Works
fine with a clean build dir now, too.
Please CC me as I'm not subscribed to this list.
--
Matthias Kretz (Germany)
http://Vir.homelinux.org/
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Index: KDE4Macros.cmake
===
--- KDE4Macros.cmake (revision 671744)
+++ KDE4Macros.cmake (working copy)
@@ -173,11 +173,18 @@
file(READ ${_abs_FILE} _contents)
get_filename_component(_abs_PATH ${_abs_FILE} PATH)
- string(REGEX MATCHALL #include +[^ ]+\\.moc[\] _match ${_contents})
+ string(REGEX MATCHALL #include +([\]moc_[^ ]+\\.cpp|[^ ]+\\.moc)[\] _match ${_contents})
if (_match)
foreach (_current_MOC_INC ${_match})
string(REGEX MATCH [^ \]+\\.moc _current_MOC ${_current_MOC_INC})
- get_filename_component(_basename ${_current_MOC} NAME_WE)
+ if(_current_MOC)
+ get_filename_component(_basename ${_current_MOC} NAME_WE)
+ else(_current_MOC)
+ string(REGEX MATCH moc_[^ \]+\\.cpp _current_MOC ${_current_MOC_INC})
+ get_filename_component(_basename ${_current_MOC} NAME_WE)
+ string(REPLACE moc_ _basename ${_basename})
+ endif(_current_MOC)
+
set(_header ${_abs_PATH}/${_basename}.h)
set(_moc${CMAKE_CURRENT_BINARY_DIR}/${_current_MOC})
@@ -196,26 +203,12 @@
endforeach (_current_MOC_INC)
endif (_match)
- set_source_files_properties(${_abs_FILE} PROPERTIES AUTOMOC_FILES ${_moc_FILES_PROPERTY})
+ set_source_files_properties(${_abs_FILE} PROPERTIES OBJECT_DEPENDS ${_moc_FILES_PROPERTY})
endif (EXISTS ${_abs_FILE} AND NOT _skip)
endforeach (_current_FILE)
endmacro (KDE4_AUTOMOC)
-macro(KDE4_GET_AUTOMOC_FILES _list)
- set(${_list})
- foreach (_current_FILE ${ARGN})
- set(_automoc_FILES_PROPERTY)
- get_filename_component(_abs_FILE ${_current_FILE} ABSOLUTE)
- get_source_file_property(_automoc_FILES_PROPERTY ${_abs_FILE} AUTOMOC_FILES)
- if (_automoc_FILES_PROPERTY)
- foreach (_current_MOC_FILE ${_automoc_FILES_PROPERTY})
-list(APPEND ${_list} ${_current_MOC_FILE})
- endforeach (_current_MOC_FILE)
- endif (_automoc_FILES_PROPERTY)
- endforeach (_current_FILE)
-endmacro(KDE4_GET_AUTOMOC_FILES)
-
macro(KDE4_CREATE_PO_FILES)
set(_list_gmo)
file(GLOB _po_files *.po)
@@ -631,13 +624,11 @@
set(_first_SRC ${_with_PREFIX})
endif (${_with_PREFIX} STREQUAL WITH_PREFIX)
- kde4_get_automoc_files(_automoc_FILES ${_first_SRC} ${ARGN})
-
if (KDE4_ENABLE_FINAL)
kde4_create_final_files(${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_final_cpp.cpp _separate_files ${_first_SRC} ${ARGN})
- add_library(${_target_NAME} MODULE ${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_final_cpp.cpp ${_separate_files} ${_automoc_FILES})
+ add_library(${_target_NAME} MODULE ${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_final_cpp.cpp ${_separate_files})
else (KDE4_ENABLE_FINAL)
- add_library(${_target_NAME} MODULE ${_first_SRC} ${ARGN} ${_automoc_FILES})
+ add_library(${_target_NAME} MODULE ${_first_SRC} ${ARGN})
endif (KDE4_ENABLE_FINAL)
if (_first_SRC)
@@ -717,14 +708,13 @@
# KDE4_ADD_EXECUTABLE(${_target_NAME} ${CMAKE_CURRENT_BINARY_DIR}/${_target_NAME}_dummy.cpp ${ARGN} )
# else (WIN32)
# under UNIX, create a shared library and a small executable, which links to this library
- kde4_get_automoc_files(_automoc_FILES ${_SRCS})
if (KDE4_ENABLE_FINAL)
kde4_create_final_files(${CMAKE_CURRENT_BINARY_DIR}/kdeinit_${_target_NAME}_final_cpp.cpp _separate_files ${_SRCS})
- add_library(kdeinit_${_target_NAME} SHARED ${CMAKE_CURRENT_BINARY_DIR}/kdeinit_${_target_NAME}_final_cpp.cpp ${_separate_files} ${_automoc_FILES})
+ add_library(kdeinit_${_target_NAME} SHARED ${CMAKE_CURRENT_BINARY_DIR}/kdeinit_${_target_NAME}_final_cpp.cpp ${_separate_files})
else (KDE4_ENABLE_FINAL)
- add_library(kdeinit_${_target_NAME} SHARED ${_SRCS} ${_automoc_FILES})
+ add_library(kdeinit_${_target_NAME} SHARED ${_SRCS})
endif (KDE4_ENABLE_FINAL)
kde4_handle_rpath_for_library(kdeinit_${_target_NAME})
@@ -758,10 +748,8 @@
set(_add_executable_param EXCLUDE_FROM_ALL)
endif (NOT KDE4_BUILD_TESTS)
- kde4_get_automoc_files(_automoc_FILES ${ARGN})
+ add_executable(${_target_NAME} ${_add_executable_param} ${ARGN})
- add_executable(${_target_NAME} ${_add_executable_param} ${ARGN} ${_automoc_FILES})
-
set_target_properties(${_target_NAME} PROPERTIES
Re: make KDE4_AUTOMOC compatible to qmake
On Thursday 07 June 2007, Christian Ehrlicher wrote: Von: Matthias Kretz [EMAIL PROTECTED] Hi, I updated the patch so that it now adds a dependency on the moc generated file and does not add the moc files in the add_library/add_executable calls. Works fine with a clean build dir now, too. Afair we had a similar discussion short after we switched to cmake. There is a difference in the moc file handling between qmake and cmake/automake. I don't remeber why this was introduced... I just successfully compiled libphonon using qmake by #including moc_name.cpp instead of name.moc. And since my KDE4Macros.cmake supports it, it also still compiles with cmake. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgp2hQJEmsSdV.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: problems compiling kdelibs
The meinproc apparently is using the wrong libs when called in kdelibs. If you install kdelibs first and then call make in the doc subdir it'll work. If you can't install because compilation fails in doc simply call make -k make install/fast the following call to make should work without error. On Tuesday 30 January 2007 15:36, Marcus Hufgard (Kalkwerk Hufgard GmbH) wrote: Hi! I want to compile the aktuall svn from kdelibs. Since yesterday i get the following error-message: meinproc: symbol lookup error: meinproc: undefined symbol: _ZN14KComponentDataC1ERK10QByte Array Do you have any idea? By Marcus -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpqF0zRBmQ51.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Undefined reference to Phonon::ObjectDescriptionModel
On Wednesday 27 September 2006 15:51, Paulo Jorge Guedes wrote: Does anybody have some idea on what the problem could be? I actually have no idea. The symbol should be defined because of kdelibs/phonon/objectdescriptionmodel.h:155. -- C'ya Matthias Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] pgpYnTmSLiVc3.pgp Description: PGP signature ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
