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: Patch for KDE4Macros to use extra target on Windows
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. Imho it's only needed for msvc - mingw doesn't need this hack. I'll test it this weekend. Christian signature.asc Description: OpenPGP digital signature ___ 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, 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. Imho it's only needed for msvc - mingw doesn't need this hack. Is cl or nmake the problem ? What about when building from VisualStudio projects ? Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: -O2 in Debug build?
On Friday 18 July 2008, Thiago Macieira wrote: Alexander Neundorf wrote: On Friday 18 July 2008, Andreas Pakulat wrote: Hi, Whats the reasoning behind using -O2 in the Debug CXX flags? A debug build shouldn't use _any_ optimizations IMHO. I think there were lengthy discussion about the flags for the different build types. I guess this was the result. /me hasn't slept a lot this week, so I don't feel like searching for this now The reason is that we split the build types in (for gcc): Release optimised for speed, qDebug/kDebug turned off, no debug symbols Release with debug info optimised for speed, debugging symbols on (-g) Debug optimised but debuggable, debugging on (-g) (-fno-reorder-blocks -fno-schedule-insns -fno-inline) DebugFull no optimisation, full debugging on (-g3) Profile DebugFull + -ftest-coverage -fprofile-arcs It is expected that the Debug build type be still debuggable with gdb without going all over the place, but still produce better performance. It's also important to note that gcc cannot detect all warning conditions unless the optimiser is active. I'd say that debug is recommended for kdelibs for people developing KDE applications, since oftentimes they may have to go into kdelibs functions. Their own code should be build under debugfull while still in development, but should be built a few times in release before a release. Thanks for the explanation :-) Can you put that on techbase, somewhere related to cmake/building ? Alex ___ 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
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? This is all I've found: http://mail.kde.org/pipermail/kde-buildsystem/2008-May/004711.html Thanks, -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: -O2 in Debug build?
On 18.07.08 23:06:50, Alexander Neundorf wrote:
On Friday 18 July 2008, Thiago Macieira wrote:
Alexander Neundorf wrote:
On Friday 18 July 2008, Andreas Pakulat wrote:
Hi,
Whats the reasoning behind using -O2 in the Debug CXX flags? A debug
build shouldn't use _any_ optimizations IMHO.
I think there were lengthy discussion about the flags for the different
build types. I guess this was the result.
/me hasn't slept a lot this week, so I don't feel like searching for
this now
The reason is that we split the build types in (for gcc):
Release
optimised for speed, qDebug/kDebug turned off, no debug symbols
Release with debug info
optimised for speed, debugging symbols on (-g)
Debug
optimised but debuggable, debugging on (-g)
(-fno-reorder-blocks -fno-schedule-insns -fno-inline)
DebugFull
no optimisation, full debugging on (-g3)
Profile
DebugFull + -ftest-coverage -fprofile-arcs
It is expected that the Debug build type be still debuggable with gdb
without going all over the place, but still produce better performance.
It's also important to note that gcc cannot detect all warning conditions
unless the optimiser is active.
I'd say that debug is recommended for kdelibs for people developing KDE
applications, since oftentimes they may have to go into kdelibs
functions. Their own code should be build under debugfull while still in
development, but should be built a few times in release before a release.
Thanks for the explanation :-)
Can you put that on techbase, somewhere related to cmake/building ?
I'm putting it on techbase in a minute (if I find the right spot).
However I'd also like to add the information to FindKDE4Internal.cmake
and more importantly make Debugfull work with CMake 2.6. As I didn't
find a reference of CMAKE_CONFIGURATION_TYPES for cmake 2.4 I've set it
only for 2.6. Please can you have a look at the attached patch and let
me know wether thats ok with you.
Andreas
--
A few hours grace before the madness begins again.
Index: FindKDE4Internal.cmake
===
--- FindKDE4Internal.cmake (Revision 833951)
+++ FindKDE4Internal.cmake (Arbeitskopie)
@@ -199,6 +199,27 @@
# _KDE4_PLATFORM_INCLUDE_DIRS is used only internally
# _KDE4_PLATFORM_DEFINITIONS is used only internally
+# Note on the possible values for CMAKE_BUILD_TYPE and how KDE handles
+# the flags for those buildtypes. FindKDE4Internal supports the values
+# Debug, Release, Relwithdebinfo, Profile and Debugfull
+#
+# Release
+# optimised for speed, qDebug/kDebug turned off, no debug symbols
+# Release with debug info
+# optimised for speed, debugging symbols on (-g)
+# Debug
+# optimised but debuggable, debugging on (-g)
+# (-fno-reorder-blocks -fno-schedule-insns -fno-inline)
+# DebugFull
+# no optimisation, full debugging on (-g3)
+# Profile
+# DebugFull + -ftest-coverage -fprofile-arcs
+#
+# It is expected that the Debug build type be still debuggable with gdb
+# without going all over the place, but still produce better performance.
+# It's also important to note that gcc cannot detect all warning conditions
+# unless the optimiser is active.
+
# Copyright (c) 2006-2008, Alexander Neundorf [EMAIL PROTECTED]
# Copyright (c) 2006, Laurent Montel, [EMAIL PROTECTED]
#
@@ -381,7 +402,6 @@
find_library(KDE4_KJS_LIBRARY NAMES kjs PATHS ${KDE4_LIB_INSTALL_DIR} NO_DEFAULT_PATH )
set(KDE4_KJS_LIBS ${kjs_LIB_DEPENDS} ${KDE4_KJS_LIBRARY} )
- find_library(KDE4_KJSAPI_LIBRARY NAMES kjsapi PATHS ${KDE4_LIB_INSTALL_DIR} NO_DEFAULT_PATH )
set(KDE4_KJSAPI_LIBS ${kjsapi_LIB_DEPENDS} ${KDE4_KJSAPI_LIBRARY} )
find_library(KDE4_KNEWSTUFF2_LIBRARY NAMES knewstuff2 PATHS ${KDE4_LIB_INSTALL_DIR} NO_DEFAULT_PATH )
@@ -897,6 +917,10 @@
if (CMAKE_COMPILER_IS_GNUCXX)
+ if(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} STREQUAL 2.6)
+ set (CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} Debugfull)
+ endif(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} STREQUAL 2.6)
+
set (KDE4_ENABLE_EXCEPTIONS -fexceptions)
# Select flags.
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO -O2 -g)
@@ -1003,6 +1027,11 @@
if (CMAKE_C_COMPILER MATCHES icc)
+
+ if(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} STREQUAL 2.6)
+ set (CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} Debugfull)
+ endif(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} STREQUAL 2.6)
+
set (KDE4_ENABLE_EXCEPTIONS -fexceptions)
# Select flags.
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO -O2 -g)
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: -O2 in Debug build?
On Saturday 19 July 2008, Andreas Pakulat wrote: Please can you have a look at the attached patch and let me know wether thats ok with you. Looks good to me, except that you're removing a find_library call for kjsapi, unrelated to what you wanted to do. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
