make -jN Works for Workspaces but not Projects

[Verax]

CodeLite 5.1
Windows 7 & 8 64-bit
Core i7 Processors
Sourcery Codebench Lite (GCC 4.7.3)

I've noticed that when rebuild my workspace (Build --> Rebuild Workspace) the compilation makes use of the "-j8" flag in global Make options (Settings --> Build Settings... --> Compiler --> Make). However, when rebuilding a single project the build is very linear and quite slow.

My make settings are simply...

Code: Select all

cs-make -j8

cs-make is the make command for Sourcery Codebench.

Is anyone else experiencing this?

[eranif]

Please post the build output (it will show use the commands executed by codelite)

Eran

[Verax]

When rebuilding a workspace, it runs the following for each project:

Code: Select all

C:\Windows\system32\cmd.exe /c "cs-make -j 8 -e -f  "Project_n.mk"  all"

Where Project_n is each project.

When rebuilding a single project, it runs the following:

Code: Select all

C:\Windows\system32\cmd.exe /c "cs-make -j 8 -e -f  "Workspace_wsp.mk""

Seems kind of backward, but that's what it does.

One of my projects has the same name as my workspace. Is that not allowed?

Actual entire output is attached.

[eranif]

Seems kind of backward, but that's what it does

This is what It was meant to do. The workspace makefile contains the dependency list

One of my projects has the same name as my workspace. Is that not allowed?

Its OK. as you might notice, workspace makefile contains a "_wsp" suffix so it won't do any harm

The build output seems OK to me. The makefile invocation also seems OK (i.e. -j8 is passed)
BTW, I don't think I ever used the build workspace functionality in codelite...
I always defined the build order and simply build the active project

Eran

[Verax]

BTW, I don't think I ever used the build workspace functionality in codelite...
I always defined the build order and simply build the active project

That's what I'd like to do, but one of my projects (AGG) makes heavy use of templates, and my dependencies don't seem to work (http://forums.codelite.org/viewtopic.php?f=11&t=2140). So I've been rebuilding the entire workspace every time I update a header file. I was hoping I could get away with re-building just the project with the updated header file, but that's too slow because it doesn't seem to honor the -j switch.

Based on the response from Gibbon1 in my previous thread, I'm wondering if maybe cs-make is to blame for my troubles.

[ColinTaylor]

I use both build/rebuild Project and build/rebuild Workspace pretty extensively and I've never noticed this difference in behaviour. I also use the Build Order feature in every project.

This is running on Windows 7 (quad core Intel core-i5) and Windows 8 (quad core + HT Intel core-i7) using the standard Codelite 5.1 installation (installed from codelite-5.1.0-mingw4.7.1.exe)

The first few lines of the rebuild workspace output on Windows 8 typically look like

Code: Select all

C:\windows\system32\cmd.exe /c "mingw32-make.exe -j 8 -e -f  "WxReusablesLib.mk"  all"
----------Building project:[ WxReusablesLib - Release ]----------
codelitegcc g++  -c  "F:/CodeliteWorkspaces/ActiveProjects/WxReusablesLib/WxStringUtilities.cpp" -O2 -Wall -mthreads -DHAVE_W32API_H -D__WXMSW__ -DNDEBUG -D_UNICODE -IE:\Dev\wxWidgets-2.9.4\lib\gcc_dll\mswu -IE:\Dev\wxWidgets-2.9.4\include -DWXUSINGDLL -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 -fno-keep-inline-dllexport     -o ./Release/WxStringUtilities.o -I. -I.
codelitegcc g++  -c  "F:/CodeliteWorkspaces/ActiveProjects/WxReusablesLib/StdStringUtilities.cpp" -O2 -Wall -mthreads -DHAVE_W32API_H -D__WXMSW__ -DNDEBUG -D_UNICODE -IE:\Dev\wxWidgets-2.9.4\lib\gcc_dll\mswu -IE:\Dev\wxWidgets-2.9.4\include -DWXUSINGDLL -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 -fno-keep-inline-dllexport     -o ./Release/StdStringUtilities.o -I. -I.
codelitegcc g++  -c  "F:/CodeliteWorkspaces/ActiveProjects/WxReusablesLib/StdTimer.cpp" -O2 -Wall -mthreads -DHAVE_W32API_H -D__WXMSW__ -DNDEBUG -D_UNICODE -IE:\Dev\wxWidgets-2.9.4\lib\gcc_dll\mswu -IE:\Dev\wxWidgets-2.9.4\include -DWXUSINGDLL -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 -fno-keep-inline-dllexport     -o ./Release/StdTimer.o -I. -I.

And the first few lines of a rebuild project look like

Code: Select all

C:\windows\system32\cmd.exe /c "mingw32-make.exe -j 8 -e -f  "ActiveProjects_wsp.mk""
"----------Building project:[ WxReusablesLib - Release ]----------"
mingw32-make.exe[1]: Entering directory `F:/CodeliteWorkspaces/ActiveProjects/WxReusablesLib'
mingw32-make.exe[1]: Nothing to be done for `all'.
mingw32-make.exe[1]: Leaving directory `F:/CodeliteWorkspaces/ActiveProjects/WxReusablesLib'
"----------Building project:[ TextEdit - Release ]----------"
mingw32-make.exe[1]: Entering directory `F:/CodeliteWorkspaces/ActiveProjects/TextEdit'
windres -i "F:/CodeliteWorkspaces/ActiveProjects/TextEdit/TextEditResources.rc" --use-temp-file --define __WXMSW__ --define _UNICODE --include-dir E:\Dev\wxWidgets-2.9.4\lib\gcc_dll\mswu --include-dir E:\Dev\wxWidgets-2.9.4\include --define WXUSINGDLL    -o ./Release/TextEditResources.rc.o
codelitegcc g++  -c  "F:/CodeliteWorkspaces/ActiveProjects/TextEdit/CppStyledTextCtrl.cpp" -O2 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DNDEBUG -D_UNICODE -IE:\Dev\wxWidgets-2.9.4\lib\gcc_dll\mswu -IE:\Dev\wxWidgets-2.9.4\include -DWXUSINGDLL -Wno-ctor-dtor-privacy -pipe -fmessage-length=0 -fno-keep-inline-dllexport   -D__WX__  -o ./Release/CppStyledTextCtrl.o -I. -I"F:\CodeliteWorkspaces\ActiveProjects"/WxReusablesLib

I certainly don't see any slower performance when building projects, so I think you're right to point the finger at cs-make

Regards, Colin