Improved CvGameCoreDLL Makefile! AND ~71% faster compilation
- Thread starter DannyDaemonic
- Start date
Asaf
Sleep Deprived
- Joined
- Mar 22, 2010
- Messages
- 1,326
Thank you for your efforts. It does compile much faster.
I have 2 issues, though:
1. When I make a change to a header file, it doesn't recompile all the needed file. I am using the makefile+fastdep 0.9 version. I copied the fastdep.exe to the bin folder and I have no error message in the output.
2. The output debug DLL is much bigger than the previous one I had... (12.3 MB vs. 15.2 MB)
I have 2 issues, though:
1. When I make a change to a header file, it doesn't recompile all the needed file. I am using the makefile+fastdep 0.9 version. I copied the fastdep.exe to the bin folder and I have no error message in the output.
2. The output debug DLL is much bigger than the previous one I had... (12.3 MB vs. 15.2 MB)
Afforess
The White Wizard
The debug dll is slightly different due to his changes. (it's also slower). You can change it back by changing this in the makefile "/ZI" to "/Zi".
Sorry to come up with a stupid guestion but what does that line do?
davidlallen
Deity
Okay, thank you. There is some much things I have no idea...
DannyDaemonic
Chieftain
- Joined
- Jun 6, 2010
- Messages
- 25
It should be working, but there could still be bugs in fastdep or the makefile. Could you attach or send me the build log (usually called 'CvGameCoreDLL.log') in a PM? Maybe you can also send me the file 'depends'. If it's not there, also let me know that. If you're going to zip them up you could include 'Makefile' just so I could make sure no unintentional changes were made or no unintentional side effects from editing are causing a problem.
Asaf said:
This has already been answered, but I'll give an official response. This makefile uses the setting from the included official vcproj file. The common makefile used before just includes "debugging information" with Debug builds. The new includes "Edit and Continue debugging information".
The second does sound more useful, but now that I think about it, you can't "edit and continue" using the free 2003 toolkit! In version 1.0 I'll change it back to just "debugging information".
Right again Afforess. With Asaf's second question, mind if I ask you, does fastdep work for you in 0.9? It's working for me but I'm worried now that there's also variance in the different nmake executables I'd have to worry about.
You're welcome.I must just say thanks to you DannyDaemonic. You made my life a lot easier.
Afforess
The White Wizard
Hmm, For the record, I should be able to add a new function in say, CvArea.h and .cpp, select "Build" (and not "Clean Build") and have it recompile any files that include CvArea.h? If that's how it works, it still doesn't work for me either.
EmperorFool
Deity
Not only that, but any file that includes a header file that includes CvArea.h, and so on. For example (not real):
Code:
// CvPlot.h
#include "CvArea.h"
// CvCity.cpp
#include "CvPlot.h"If CvPlot.h includes CvArea.h, then changing CvArea.h should cause any file that includes CvPlot.h to be recompiled, such as CvCity.cpp in the fake example above.
davidlallen
Deity
There are two separate features mentioned in the OP: using precompiled headers, and using "real" dependencies to reduce the number of files compiled. The second one is what is giving you trouble here. When I started compiling the sdk a few months ago, I also looked at the second one. I did not count exactly, but almost every .cpp file includes almost every .h file. It is over 90% "dense". This means that when it is operating correctly, "real" dependencies will save almost nothing. So I did not pursue any further about using "real" dependencies.
However, I bet that most of the speedup is coming from precompiled headers, not from "real" dependencies. I did not investigate into this one. If there is an obvious compile option to use precompiled headers, and it is possible to use that by itself, you may get most of the speedup without running into dependency problems.
However, I bet that most of the speedup is coming from precompiled headers, not from "real" dependencies. I did not investigate into this one. If there is an obvious compile option to use precompiled headers, and it is possible to use that by itself, you may get most of the speedup without running into dependency problems.
Asaf
Sleep Deprived
- Joined
- Mar 22, 2010
- Messages
- 1,326
Thank you everyone for your comments.
So regarding the debug DLL size - changed to /Zi, still bigger, but no as much. I guess I can look at the rest of the compile and link flags later. Doesn't really matter.
Regarding the dependencies - I found the problem. You compiled fastdep with VS2010, and I was missing a DLL.
Installing the relevant VC++ redistributable solved the problem, though it feels like it doesn't work as fast now, but still faster than the original. I could be wrong, though.
You should probably add an error message when fastdep fails to run.
Thanks again.
So regarding the debug DLL size - changed to /Zi, still bigger, but no as much. I guess I can look at the rest of the compile and link flags later. Doesn't really matter.
Regarding the dependencies - I found the problem. You compiled fastdep with VS2010, and I was missing a DLL.
Installing the relevant VC++ redistributable solved the problem, though it feels like it doesn't work as fast now, but still faster than the original. I could be wrong, though.
You should probably add an error message when fastdep fails to run.
Thanks again.
DannyDaemonic
Chieftain
- Joined
- Jun 6, 2010
- Messages
- 25
The 71% speed up I measure is only from the precompiled headers.
Using fastdep can literally save you >99% of percent of the rebuild time, but there's simply no fair way to put a speed up on that functionality. First of all, how often do you edit a header file? Secondly, the speed up saved by avoiding the rebuild-all varies based on how many source files include the edited header.
If debug size is a real issue for everyone I could see what flags the currently popular makefile uses. With version 1.0 I've already committed to changing over to /Zi for debug mode. (There are only advantages to this.) Again, in my defense, I just loaded up the original project files included with Civ4 and copied the setting right out of there into my new makefile.
Thanks for spotting that! I was getting frustrated chasing that down. Normally such an error will cause Windows to pop up a message box or something along those lines. I forgot to statically link the binary. I'll have to do that, or compile it with VC6, or the 2003 toolkit.Asaf said:
I timed the fastdep and it was less than a 10th of a second in debug mode. I can't imagine it actually adds any noticeable overhead. It's done once at the start of the build. I'll test it again before my 1.0 release.
Glad to hear it.thanks DannyDaemonic, really enjoying this
Asaf
Sleep Deprived
- Joined
- Mar 22, 2010
- Messages
- 1,326
No need to apologize. You're doing us all a favor
It does produce a message box when you run fastdep separately (this is how I found that). When you run it from the makefile the message box does not appear. Not sure how they do it exactly.
It was just my feeling, and I don't know if it's justified. It still feels much faster than the original. No need to do extra work for this on my account.
My first post here!
Your makefile is real faster and well done. Gz!
That's true.
I've noticed another bug in civ4col sdk (included in steam):
Line 36 in CyPlayerInterface3.cpp :
with the "educationThreshold' : is not a member of 'CyPlayer'" error message. I've removed this line, compilation is ok then. But I don't know if the game will run. And I would like to find where "educationThreshold" is defined.... removing a line is never a good thing.
Your makefile is real faster and well done. Gz!
That's true.
I've noticed another bug in civ4col sdk (included in steam):
Line 36 in CyPlayerInterface3.cpp :
Code:
.def("educationThreshold", &CyPlayer::educationThreshold, "int ()")Okay, I finally found time and energy to try your awesome makefile. And I must admit that it IS indeed quite fast. 
But I had some hard time getting it to work. But now I can't find a solution for this error:
Any idea what's wrong? I noticed the only place I had 'afxres.h' is in the C:/Program Files/Microsoft Platform SDK.
But I had some hard time getting it to work. But now I can't find a solution for this error:
Code:
1>FAssert.cpp
1> "C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin\cl.exe" /nologo /MD /O2 /Oy /Oi /G7 /DNDEBUG /DFINAL_RELEASE /Fp"Release\CvGameCoreDLL.pch" /GR /Gy /W3 /EHsc /Gd /Gm- /DWIN32 /D_WINDOWS /D_USRDLL /DCVGAMECOREDLL_EXPORTS /Yu"CvGameCoreDLL.h" /DLOG_AI /D_MOD_FRACTRADE /D_MOD_SENTRY /D_MOD_GOVWORKERS /IBoost-1.32.0/include /IPython24/include /I"C:\Program Files\Microsoft Visual C++ Toolkit 2003/include" /I"C:/Program Files/Microsoft SDKs/Windows/v6.0A/Include" /I"C:/Program Files/Microsoft SDKs/Windows/v6.0A/Include/mfc" /I"CxImage/general" /I"CxImage/jpeg" /FoRelease\FDialogTemplate.obj /c FDialogTemplate.cpp
1>FDialogTemplate.cpp
1> "C:/Program Files/Microsoft SDKs/Windows/v6.0A\bin\rc.exe" /FoRelease\CvGameCoreDLL.res /IBoost-1.32.0/include /IPython24/include /I"C:\Program Files\Microsoft Visual C++ Toolkit 2003/include" /I"C:/Program Files/Microsoft SDKs/Windows/v6.0A/Include" /I"C:/Program Files/Microsoft SDKs/Windows/v6.0A/Include/mfc" /I"CxImage/general" /I"CxImage/jpeg" CvGameCoreDLL.rc
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>CvGameCoreDLL.rc(10) : fatal error RC1015: cannot open include file 'afxres.h'.
1>NMAKE : fatal error U1077: '"C:/Program Files/Microsoft SDKs/Windows/v6.0A\bin\rc.exe"' : return code '0x1'
1>Stop.
1>Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"
1>Build log was saved at "file://d:\CvGameCoreDLL\CvGameCoreDLL\Release\BuildLog.htm"
1>CvGameCoreDLL - 3 error(s), 0 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========Afforess
The White Wizard
I had the same error. change where in says afxres.h to "windows.h" and it will compile.
I had the same error. change where in says afxres.h to "windows.h" and it will compile.
Thanks that seems to work, for that problem. Now it seems that I couldn't add the CxImage folder correctly:
Spoiler :
Afforess
The White Wizard
A quick and dirty fix for that would be to dump all of the files from that folder into your CvGameCoreDLL folder. DannyDaemonic will probably have a cleaner solution later.
Hm okay, I'll try that. BTW aren't those files in AND sources too? What did you do to get them work?
Similar threads
