Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Error building codeblocks 7860
Jenna:
--- Quote from: oBFusCATed on February 28, 2012, 05:48:25 pm ---Morten:
Yes, if we just disable the pre-compiled headers and leave all the includes the way they are it will be slower. Because every file includes every file from the SDK, no mater if it needs it or not.
Also as far as I've read about pre-compiled headers, there should be used only for external libs, not for internal stuff, because they cause the pains I'm having.
Removing the PCH should be involving process and will take a lot of effort.
p.s. the full build (full as a build with all plugins, bootstrapping and make install phaze) on linux without pre-compiled headers using autotools takes around 10 minutes. I've not tried what is the time with pch. I'll do a test later and will report my findings.
--- End quote ---
Are you sure it's without pch's ?
By default the automake-system uses pch's (not autotools in general, but our configuration).
--- Quote from: oBFusCATed on February 28, 2012, 05:48:25 pm ---
--- Quote from: MortenMacFly on February 28, 2012, 05:21:33 pm ---Still my favourite is to fix the actual error (if any) - however, I usually don't have this trouble. But I also don't know what is different, except the platform (Windows / Linux).
--- End quote ---
This is another matter and it is unrelated to the disabling of pch.
--- End quote ---
I think whatr Morten wants to say, is to fix the bug, that leads to the problems with pch's.
And that is not unrelated to disabling them in general.
oBFusCATed:
--- Quote from: jens on February 28, 2012, 06:14:34 pm ---Are you sure it's without pch's ?
By default the automake-system uses pch's (not autotools in general, but our configuration).
--- End quote ---
I'm always building with --disable-pch which is documented as disabling pchs, also it breaks when the pch build is broken.
--- Quote from: jens on February 28, 2012, 06:14:34 pm ---I think whatr Morten wants to say, is to fix the bug, that leads to the problems with pch's.
--- End quote ---
I know and I agree that the bug should be fixed. As I'm the one who started this discussion. :)
--- Quote from: jens on February 28, 2012, 06:14:34 pm ---And that is not unrelated to disabling them in general.
--- End quote ---
It is :)
MortenMacFly:
--- Quote from: jens on February 28, 2012, 06:14:34 pm ---
--- Quote from: oBFusCATed on February 28, 2012, 05:48:25 pm ---
--- Quote from: MortenMacFly on February 28, 2012, 05:21:33 pm ---Still my favourite is to fix the actual error (if any) - however, I usually don't have this trouble. But I also don't know what is different, except the platform (Windows / Linux).
--- End quote ---
This is another matter and it is unrelated to the disabling of pch.
--- End quote ---
I think whatr Morten wants to say, is to fix the bug, that leads to the problems with pch's.
And that is not unrelated to disabling them in general.
--- End quote ---
Yes, that's what I meant - find the reason why it doesn't work an fix it. However, as it seems to depend on the platform it may not be our fault at all, but the compiler used could be another reason. And the fact that I can hardly reproduce on Windows makes me believe so.
In fact what we do is plain right: If the header file is set to be compiled first (which is is due to the weight) and it has changed (which we figure out by its date and dependencies) it will be re-compiled. The rest is done by the compiler.
Reasons why it does not work maybe:
1.) The date is wrong
2.) The dependencies are calculated wrong
3.) The compiler pre-compiles wrong
4.) (for me most likely) when we start build processes in parallel we don't consider a special handling for PCHs. Consider you start 3 build processes, where the first two are the PCH's and the next one is already part of the SDK.
However, if 4.) is true it should always work in a second trial.
MortenMacFly:
--- Quote from: oBFusCATed on February 28, 2012, 06:29:17 pm ---I'm always building with --disable-pch which is documented as disabling pchs, also it breaks when the pch build is broken.
--- End quote ---
Yes, and I guess I know why that is - I'll commit a fix I had prepared for that... gimme some time...
UPDATE: Done.
oBFusCATed:
Some benchmarks:
--- Code: ---no pch all plugins
real 6m3.471s
user 17m28.232s
sys 1m4.067s
with pch all plugins
real 5m29.323s
user 15m29.386s
sys 1m4.443s
no pch core only
real 2m16.697s
user 6m47.092s
sys 0m22.004s
with pch core only
real 1m55.610s
user 5m17.441s
sys 0m21.784s
--- End code ---
Linux, make -j5, gcc 4.5.3 core2quad 6600 @ 3.2 ghz.
I don't see what is the benefit of pch. I see only pain...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version