Changeset 992 for trunk/qmake/generators/os2/gnumake.cpp

Timestamp:

Aug 16, 2011, 6:51:56 PM (14 years ago)

Author:

Dmitry A. Kuminov

Message:

qmake: Reverted r976 and reapplied r804.

Adding dependencies to Makefiles themselves doesn't solve all
problems since sometimes the proper .prl file is created not at
the relevant subdir target's Makefile generation time but at a later
stage, when that subdir is built (which may also involve nested
subdirs). So we simply disable parallelism for subdirs Makefiles
at all again.

File:

• trunk/qmake/generators/os2/gnumake.cpp (modified) (1 diff)

trunk/qmake/generators/os2/gnumake.cpp

@@ -360 +360 @@
     else if(project->first("TEMPLATE") == "subdirs") {
         writeSubDirs(t);
+        if (project->isActiveConfig("ordered")) {
+            // Ordered builds are usually used when one sub-project links to
+            // another sub-project's library. Sometimes detecting the proper
+            // library name (e.g. the version suffix) requires at least a .prl
+            // for that library to exist. The .prl is created by qmake at Makefile
+            // generation time and these qmake calls are not actually ordered at
+            // dependency level so in case of parallel builds they may get
+            // executed simultaneously which breaks the build. It is not really
+            // possible to order them using dependencies because there are usually
+            // several target's flavors all depending on its Makefile and it's
+            // impossible to detect which flavor of the "parent" target this
+            // make file should depend on (depending on the "parent"'s Makefile
+            // is not enough because the required libraries may be generated by
+            // its own sub-projects at a later stage). One case showing this
+            // behavior is designer.exe depending on QtDesignerComponents.lib.
+            //
+            // The only solution to this is to disable parallelism for subdirs
+            // Makefiles completely. Which is not a big deal since "ordered"
+            // implies sequential building any way.
+            t << ".NOTPARALLEL:" << endl << endl;
+        }
         return true;
     }