precompiled prefix header

[alex25]

what about:
local_env.Append(CCFLAGS = '-include #/include/pch.h')

i've committed a fix to the build environment:

env.MergeFlags('-include pch.h')

now gcc finds the relevant header. still not convinced this whole pch.h business is worth it though.

--alex--

[thelusiv]

Hmmm the MergeFlags fix doesn't seem to work for me, is that a new SCons feature? What version are you using Alex?

[alex25]

Hmmm the MergeFlags fix doesn't seem to work for me, is that a new SCons feature? What version are you using Alex?

the one that comes with debian unstable: 0.96.93.

--alex--

[reece146]

Any news about this? I'm stuck on the MergeFlags thing too...

Code:

AttributeError: SConsEnvironment instance has no attribute 'MergeFlags':
File "SConstruct", line 313:
env.MergeFlags('-include pch.h')

(scons-0.96.1)

Edit: Gentoo peoples: 0.96.94 is in unstable and seems to get past this.

[abs1nth]

mergeflags seems to need the latest unstable scons

try replacing
env.MergeFlags('-include pch.h')
with
env.Append(CXXFLAGS = '-include pch.h')

[alex25]

mergeflags seems to need the latest unstable scons

try replacing
env.MergeFlags('-include pch.h')
with
env.Append(CXXFLAGS = '-include pch.h')

did you try it? on my scons it keeps adding quotes around -include pch.h and gcc won't recognize it. anyway, the more it think about this pre compiled header idea (whatever that means) the dumber i think it is. it's probably time to go back to each file including the header files it needs. just out of curiosity, how exactly did you test the compilation times when it doesn't really seem to compile for anybody?

--alex--

[thelusiv]

I think I have a fix checked into SVN. I have turned off the MergeFlags line and put

Code:

#include "pch.h"

in all the files that need it.

Now, to use the precompiled header...you need to first compile it (SCons doesn't do this for you properly, yet).

Code:

g++ include/pch.h

This will produce a file include/pch.h.gch, and gcc/g++ will automatically pick it up and use it instead when it compiles vdrift.

As for performance, with the header pre-compiled I can't quite tell the difference at all. Either way it seems to always take my new machine about 44 seconds to compile. Perhaps it's not actually using the pre-compiled header when it is there...?

[abs1nth]

did you try it? on my scons it keeps adding quotes around -include pch.h and gcc won't recognize it.

as a matter of fact i tried it and it worked fine (v0.96.92)

anyway, the more it think about this pre compiled header idea (whatever that means) the dumber i think it is. it's probably time to go back to each file including the header files it needs.

well i think multiplying hundreds of code lines is dumb ^^
the pain grew since definitions.h was added...
(i'm not talking about the multiplied system includes but the multiplied conditional macros for mac/win)

sorry for the whole mess but i couldn't forsee that it's apartently impossible to add a simple flag to gcc with (the latest stable) scons.

just out of curiosity, how exactly did you test the compilation times when it doesn't really seem to compile for anybody?

i'm using Xcode on a mac ;o)

[alex25]

well i think multiplying hundreds of code lines is dumb

well, this is how scons or make manage dependencies by having each file include the header files it needs. change a header file and you recompile only the files that depend on it. now that everything is in one giant header, change one header file and recompile everything. i wouldn't really call this duplication of code, i would call it smart dependency management. now, if you were to read up on large scale software development i don't think you would find one person advocating putting all the header files in one giant header. on the contrary (look at unix headers, etc. even macos, since it's based on freebsd, does the same thing with the system header files).

--alex--

[abs1nth]

now that everything is in one giant header, change one header file and recompile everything.

well the system headers aren't supposed to change often or at all.

of course there is the problem that we also include definitons.h (in pch.h) which changes with every svn revision, definitely a problem if we really want to precompile the header - but right now i mainly advocated the thing to get rid of the massive distribution of #ifdef __APPLE__ all over the source base. if we want to pre-compile it we have to take the include of definitions.h out of there of course, or include the REVISION in some other way.

[alex25]

well the system headers aren't supposed to change often or at all.

they do, on a real system :wink: i track cvs/svn for a lot of the packages vdrift depends on (mesa, sdl, openal, etc). the apple stuff should've gone in some compatibility header (same with windows or unix specific stuff). for the rest, each file should include the header files in needs. let's not reinvent (badly) the wheel.

oh, and speaking of definitions.h. it shouldn't be in svn as it is automatically generated. i get a conflict every time i do an svn update but i've learned to ignore it.

--alex--

[abs1nth]

I've just taken definitions.h out of pch.h.

i doubt many people track svn versions of system packages ;o)

yeah i wondered why definitions.h is in svn just a minute ago.

[thelusiv]

Yeah, definitions.h should really be removed from SVN. It is always generated, the only reason I added it was so that people on other platforms would notice that they need to replace it.

[abs1nth]

the only reason I added it was so that people on other platforms would notice that they need to replace it.

the message i've got is to work around its existence

[thelusiv]

definitions.h has been removed from SVN.