Official support for precompiled headers

[karnon]

well , I do the test, stdafx.h is setting to pre-compile header in codelite:
------stdafx.h-------
#ifndef STDAFX_H
#define STDAFX_H
#include <string>
#include <iostream>
#include <boost/xpressive/xpressive.hpp>
#endif
----------main.cpp--------
#include "stdafx.h"
using namespace std;

int main(int argc, char **argv)
{
int i;
i = 3;
i++;
boost::xpressive::sregex r1;
cout<<"hji"<<endl;
return 1;
}
--------------------------------

And first build:
----------Build Started--------
C:\WINDOWS\system32\cmd.exe /c ""mingw32-make.exe" -j 2 -f "codeliteworkspace_wsp.mk""
----------Building project:[ testxpressive - Debug ]----------
g++ -c F:\tmp\codeliteworkspace\stdafx.h -g "-ID:/boost_1_41_0"
g++ -c "F:/tmp/codeliteworkspace/main.cpp" -g -o ./Debug/main.o "-ID:/boost_1_41_0"
g++ -o ./Debug/testxpressive ./Debug/main.o "-L."
----------Build Ended----------
0 errors, 0 warnings, total time: 00:00:29 seconds

It need 29 seconds.

And do small change to main.cpp(e.g, i=3;i--;) , recompile project:
----------Build Started--------
C:\WINDOWS\system32\cmd.exe /c ""mingw32-make.exe" -j 2 -f "codeliteworkspace_wsp.mk""
----------Building project:[ testxpressive - Debug ]----------
mingw32-make.exe[1]: `F:\tmp\codeliteworkspace\stdafx.h.gch' is up to date.
g++ -c "F:/tmp/codeliteworkspace/main.cpp" -g -o ./Debug/main.o "-ID:/boost_1_41_0"
g++ -o ./Debug/testxpressive ./Debug/main.o "-L."
----------Build Ended----------
0 errors, 0 warnings, total time: 00:00:20 seconds

Only 6 seconds improvement. It is still quite a long time for only small change in main.cpp.

In command line,type:
g++ main.cpp -H
Output is:
------------------------------
! stdafx.h.gch
main.cpp
main.cpp
------------------------------
Compile main.cpp with *.gch only need a second under command line.

So.... is there something wrong in my testing? I thought 20 seconds is toooo long time for a re-compile, I guess there must be something wrong..... I guess most time is spent on something about analyzing stdafx.h.

If I remove boost/xpressive, then compiling time is just a second again. So, I think this test is enough to make me belive something wrong....isn't it?

I do lots of testing to try to find out what's wrong here, but all I can do now is guessing what's happening...Pre-compile is important to me. I don't want to wait 20 seconds every time, and it's getting worse if more header files were included in stdafx.h, especially header-only libraries.

[karnon]

I think I found the key...
I disable the option " use compiler -MT switch generate source dependencies files(*.o.d)" , then every thing works as I excepted.
What is option for ??

[eranif]

If you disable this option, codelite will not generate the .o.d files - which includes the dependencies file needed by the makefile.

Each .o.d file includes in it a list of dependencies files for the given file.

This might indicates a bug in the dependencies file rule in the generated makefile
Eran

[karnon]

So, most time is spent on generating dependencies?
Is is possible in the future only generating *.o.d files when it's "necessary" ? eh...I know it is not an easy challenge.
I have a idea. Before compiling, remove all "#include 'stdafx.h' " statement in source code, and "manually" add make-file rule for stdafx.h( Of cause, here "manual" is done by codelite).

And I found this in gcc manual, maybe a little help:
-MM
Like -M but do not mention header files that are found in system header directories, nor header files that are included, directly or indirectly, from such a header.

This implies that the choice of angle brackets or double quotes in an `#include' directive does not in itself determine whether that header will appear in -MM dependency output. This is a slight change in semantics from GCC versions 3.0 and earlier.

[eranif]

And I found this in gcc manual, maybe a little help:
-MM
Like -M but do not mention header files that are found in system header directories, nor header files that are included, directly or indirectly, from such a header.

Open the .mk file of your project, and you will see that codelite already uses the -MM flag

Like I said, I will look into it (didnt have a chance yet)

Eran

[eranif]

Like I said, I will look into it (didnt have a chance yet)

I found the problem: each .o.d file is dependent on the modification made on the relevant .cpp file, so if you have a file named:
main.cpp, codelite will generate rule like this:

Code: Select all

main.o.d: main.cpp
     g++ -MT ... 

The simple (and I think the correct one) solution is to do it the qmake way:
- Dont make the the .o.d file dependent on any file, but its own existence (if it is not there, create it)
- Add new option in the build menu 'Clean dependencies' (so on the next build they will be auto-generated)

Eran

[eranif]

Like I said, I will look into it (didnt have a chance yet)

I found the problem: each .o.d file is dependent on the modification made on the relevant .cpp file, so if you have a file named:
main.cpp, codelite will generate rule like this:

Code: Select all

main.o.d: main.cpp
     g++ -MT ... 

The simple (and I think the correct one) solution is to do it the qmake way:
- Dont make the the .o.d file dependent on any file, but its own existence (if it is not there, create it)
- Add new option in the build menu 'Clean dependencies' (so on the next build they will be auto-generated)

Eran

After further investigation of the code and experimenting with the makefile, it seems that I cant remove the dependency of the .o.d file (the dependency file) and the .cpp file. Consider the following:
You are adding a new include file to the .cpp file (not to the pre-compiled header), if we remove the dependency between the .o.d and the .cpp, the o.d will not be re-generated (since now it needs to produce a new rule with the new header file included) - which is bad.

The only real solution is to implement my own "file crawler" to collect include files -> but I really dont want to do it instead of using the MT/MM flag of gcc

Eran

[karnon]

Dependency is a headache...
I have a suggestion:
1, force stdafx.h is guarded, i.e. beginning with #if define STDAFX_H
2, when generating .o.d files, using "-DSTDAFX_H" so "#include stdafx.h" will not be included
3, if stdafx.h is changed , regeneration *.o.d for all cpp files.