Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Compiler and project file changes in latest SVN.
rickg22:
Yiannis: YAY! :D
I'll update my SVN today and compare the generation times!
P.S. Did you read my post on the macrosmanager optimization?
mandrav:
--- Quote from: killerbot on November 28, 2005, 04:18:20 pm ---Great, any changes (next to those other project changes) with respect to "http://forums.codeblocks.org/index.php/topic,1478.0.html" (otherwise I still need to file it). :P
--- End quote ---
Not yet, but will be fixed too.
--- Quote from: Urxae on November 28, 2005, 04:32:52 pm ---
--- Quote from: mandrav on November 28, 2005, 04:07:09 pm ---PCH mode now defaults for PCH to be created in the object output directory.
--- End quote ---
I saw this change in the Subversion logs and was just about to start a topic asking why this change was made. Guess I'll ask here.
My problem: doesn't this break code like
--- Code: ---#include "precompiled_header.h"
--- End code ---
when said file is indeed in the same directory?
And when I say "break", I mean: does it still use the precompiled header? Wouldn't it find the actual header first?
--- End quote ---
It works now. Update your sources :)
mandrav:
--- Quote from: rickg22 on November 28, 2005, 05:26:39 pm ---P.S. Did you read my post on the macrosmanager optimization?
--- End quote ---
Yes, but I wait for *your* speed measurements :)
Urxae:
--- Quote from: mandrav on November 28, 2005, 06:13:25 pm ---
--- Quote from: Urxae on November 28, 2005, 04:32:52 pm ---
--- Quote from: mandrav on November 28, 2005, 04:07:09 pm ---PCH mode now defaults for PCH to be created in the object output directory.
--- End quote ---
I saw this change in the Subversion logs and was just about to start a topic asking why this change was made. Guess I'll ask here.
My problem: doesn't this break code like
--- Code: ---#include "precompiled_header.h"
--- End code ---
when said file is indeed in the same directory?
And when I say "break", I mean: does it still use the precompiled header? Wouldn't it find the actual header first?
--- End quote ---
It works now. Update your sources :)
--- End quote ---
I did. But I'd just finished a long recompile and didn't feel like doing one again, especially if I wasn't sure it'd work.
How did you fix it, by the way? Is there an option to add a library to the "" search path? I wouldn't be surprised if there was, I'd just like to know what it is as I searched for it and couldn't find it a while back.
I'd look at the commit in detail, but it's a mixed one with lots of changes...
EDIT: Oh, you meant update them again, as in you just fixed it?
By the way, is it really a good idea to put all C::B SDK headers into a precompiled header and have pretty much everything depend on it? One change to macrosmanager.h and it's an almost full rebuild :(.
I myself usually use pchs only for stuff that actually doesn't change for large amounts of time only: windows.h and headers for libraries like wxWidgets and Boost.
They're meant to cut down compilation time, but if you put your own (changing) stuff in there they may actually increase it by increasing dependencies.
rickg22:
--- Quote from: Urxae on November 28, 2005, 06:28:51 pm ---By the way, is it really a good idea to put all C::B SDK headers into a precompiled header and have pretty much everything depend on it? One change to macrosmanager.h and it's an almost full rebuild :(.
--- End quote ---
PCH or not, a change in the SDK headers will require a full rebuild. My full rebuild takes about 7 mins with PCH, 11 minutes without. Anyway, don't think we'll be doing SDK changes so often... this was because of an extraordinary bug and optimization. And the *managers are a fundamental part of the SDK. Don't expect changes like these very often.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version