Bug report #2880
makefiles not parallel building proof
Status: | Closed | ||
---|---|---|---|
Priority: | Low | ||
Assignee: | - | ||
Category: | Build/Install | ||
Affected QGIS version: | Regression?: | No | |
Operating System: | All | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | Copied to github as #: | 12940 |
Description
In times of multi-core machines it is not too uncommon to compile projects like QGIS with "make -j9" or even higher. This does not work, however, as the compile process bails out. Not a big thing, lowering it to -j6 makes it work, but the error shows a build dependency problem in the makefiles that should be fixed.
Here is a part of the log:
make -j9 Scanning dependencies of target qgis.d.rast Scanning dependencies of target compile_python_files Scanning dependencies of target svnversion Scanning dependencies of target qgis.g.info Scanning dependencies of target ui Scanning dependencies of target qgis.g.browser Scanning dependencies of target pluginstaller [ 0%] [ 0%] [ 0%] [ 0%] [ 0%] [ 0%] [ 0%] Building C object src/providers/grass/CMakeFiles/qgis.g.info.dir/qgis.g.info.c.o Building C object src/providers/grass/CMakeFiles/qgis.d.rast.dir/qgis.d.rast.c.o Built target svnversion Generating ui_qgsplugininstallerbase.py Generating ui_qgssinglesymboldialogbase.h Generating ui_qgssymbolv2propertiesdialogbase.h Generating ui_qgsformannotationdialogbase.h Scanning dependencies of target mapserverexport [ 0%] [ 0%] [ 0%] [ 0%] Generating ui_qgsplugininstallerfetchingbase.py Generating ui_qgsplugininstallerinstallingbase.py Generating ui_qgsprojectpropertiesbase.h Generating ui_qgsmapserverexportbase.py [ 0%] Building CXX object src/plugins/grass/CMakeFiles/qgis.g.browser.dir/qgis.g.browser.cpp.o [ 0%] Generating ui_qgscontinuouscolordialogbase.h [ 0%] Linking C executable qgis.g.info Generating ui_qgisappbase.h Linking C executable qgis.d.rast [ 0%] Generating ui_qgscomposerbase.h [ 0%] [ 0%] Built target compile_python_files Generating ui_qgspgnewconnectionbase.h [ 0%] [ 0%] Warning: name gridLayout is already used Generating ui_qgsitempositiondialogbase.h [ 0%] Generating resources_rc.py Generating ui_qgsrulebasedrendererv2widget.h [ 0%] [ 0%] [ 0%] Built target qgis.d.rast Built target mapserverexport Generating ui_qgsludialogbase.h [ 0%] Generating ui_qgsplugininstallerpluginerrorbase.py [ 0%] Scanning dependencies of target ftools [ 0%] Scanning dependencies of target gdaltools [ 0%] Generating ui_qgscomposeritemwidgetbase.h Generating ui_qgsplugininstallerrepositorybase.py [ 0%] Generating ui_qgscomposervectorlegendbase.h Generating ui_qgsuniquevaluedialogbase.h [ 0%] [ 0%] [ 0%] Generating resources_rc.py Generating ui_frmAbout.py Generating ui_qgspluginmanagerbase.h [ 0%] [ 0%] [ 0%] Generating resources_rc.py Generating ui_qgsattributeactiondialogbase.h Built target gdaltools [ 0%] [ 0%] Built target qgis.g.info Scanning dependencies of target osmplugin Generating ui_qgspgsourceselectbase.h [ 0%] [ 0%] Generating ui_qgsbookmarksbase.h Scanning dependencies of target ftools_tools Generating ui_OsmFeatureDW.py [ 0%] maker2: *** No rule to make target @python/plugins/fTools/ui_frmAbout.py', needed by @python/plugins/fTools/tools/CMakeFiles/ftools_tools'. Stop. maker1: *** [python/plugins/fTools/tools/CMakeFiles/ftools_tools.dir/all] Error 2 maker1: *** Waiting for unfinished jobs....
History
#1 Updated by sharpie - about 14 years ago
The 1.5.0 source won't build with anything above -j1 for me. Makes development work a bit tedious as it takes a good 5 minutes to compile or recompile.
#2 Updated by Anne Ghisla almost 14 years ago
I regularly compile with make -j4 on my dual core, since a long time, both on Debian and Fedora. Does this bug affect Gentoo only?
#3 Updated by Volker Fröhlich almost 14 years ago
No, not specific to Gentoo. I've seen it happen with -j 16.
#4 Updated by Volker Fröhlich over 13 years ago
- Assignee deleted (
nobody -)
The problem seems gone with version 1.7. I took multiple runs with up to 30 workers.
Can somebody confirm that?
#5 Updated by Volker Fröhlich about 13 years ago
- Pull Request or Patch supplied set to No
- Status changed from Open to Closed
As I mentioned before, I haven't seen that happen for quite some time with a high number of workers. Please re-open if I'm wrong.