Proper Precompiled Header usage.

[mkultra333]

I set up a project to use precompiled headers based on the wiki article, http://www.ogre3d.org/tikiwiki/tiki-ind ... ed+headers.
It worked fine. Now I've also added recast/detour. But it won't compile unless I #include "stdafx.h" at the top of all the recast/detour cpp files.

So I did that, and I decided to add the recast/detour files to the precompiled headers as well. I added all the recast headers to stdafx.h. So it all compiles fine.

But I'm wondering, isn't this all a bit weird? It looks to me as if the recast cpp files are now including all the ogre headers, which they don't need, and a bunch of other files that only needed the ogre includes now have the recast includes as well. Everything with that includes stdafx.h is now using everything.

Is that normal? What's the proper thing to do? Should I be using more than one PCH, so for instance stdafx1.h, stdafx2.h, for different file groups? I'm guessing that wouldn't work.

[bstone]

That's normal. And you don't want to mess with multiple PCHs, believe me

If you don't want to include "stdafx.h" in recast/detour then just make a separate static library project for it and disable precompiled headers there.

[zootlewurdle]

Everything with that includes stdafx.h is now using everything.

Which is pretty much why precompiled headers are a bad idea. It means developers will get lazy about deciding exactly what each header file or cpp file actually *needs*. You'll start getting into a mess with regards to dependencies. Plus, if you later want to take that project to another platform where precompiled headers are not supported, you'll get far higher compile times than had you not used precompiled headers in the first place. Not to mention the weird bugs that can creep in as a result of VS choosing not to regenerate the pch when it should have. Been there, done that. I'll never touch precompiled headers again.

[CABAListic]

I tend to agree. If you want to reduce compile time, I've found unity builds a much better option. I wasn't convinced at first, but I've integrated the option with Ogre's CMake build system, and if you enable the OGRE_UNITY_BUILD option, you'll notice a significant speedup in Ogre compilation time.

[Brocan]

I tend to agree. If you want to reduce compile time, I've found unity builds a much better option. I wasn't convinced at first, but I've integrated the option with Ogre's CMake build system, and if you enable the OGRE_UNITY_BUILD option, you'll notice a significant speedup in Ogre compilation time.

Yeah, the ogre's compile speed time using unity builds is amazing

[bstone]

What's good for a monolithic code is not necessarily good for the regular development cycle in the integrated environment. The precompiled headers have their disadvantages but the trade off is negligible. I can't remember having any issue with dependencies or .pch files and I mean through years. Not that it comes for granted, you need some discipline, but still. One good practice for me was replacing the precompiled headers source (e.g. stdafx.h) with an empty file and making a full build once in a while. That for one will keep your dependencies in good shape.

Up to and including MSVC 2008 I managed to have almost instant (a few seconds) intermediate builds (i.e. updated a few files, ran Build) for rather large projects. Unfortunately that became the past with MSVC 2010. But unlikely that precompiled headers are the reason. The new build system is just crap. I have yet to figure out why it sometimes takes a few minutes to compile one .cpp file while it compiles instantly the next few times.

[jacmoe]

A very common trap you fall into when using precompiled headers is that dependencies turn implicit.
Probably why Recast (if using the VS project file) fails to compile without.

So, if you do use it, make it a rule to ensure that it also builds with precompiled headers turned off.

[mkultra333]

I thought unity builds were just handy for working on the full Ogre source. Are they handy for projects using the ogre dlls as well?

At any rate, I'll probably stick with PCH for now, it seems to work ok and this project (an editor) isn't that huge.

I remember when my main project (a game) used ogre 1.6, it built really quickly. Then suddenly when I moved to 1.7 the compile time jumped a lot, to about 30 seconds or so. Since then I've gotten a new rig with faster CPU and all the project stuff is on an SSD, so the compile time is much better. But I also work on a laptop sometimes, and that was taking 30-40 seconds or so to compile stuff. So I experimented with PCH on the editor and it goes down to about 10 seconds for a typical build, which is fine. My game, I don't use PCH, just to keep things a bit cleaner.

Oh, and thanks for the info bstone. Glad I'm not doing anything wrong, and it is just a bit weird that all that stuff gets included everywhere.

(Edit: Side note, at one stage I was doing an experiment mixing in Cube game code, and the compile time jumped to 6 minutes on my old rig. I just couldn't work like that, and don't really understand how people can function once compile times go over 30-40 seconds.)

[lingfors]

I tend to agree. If you want to reduce compile time, I've found unity builds a much better option. I wasn't convinced at first, but I've integrated the option with Ogre's CMake build system, and if you enable the OGRE_UNITY_BUILD option, you'll notice a significant speedup in Ogre compilation time.

Argh! Why didn't you tell us earlier?

I've seen it in the CMake options before, but I connected it to Unity3D. Since I didn't get what Ogre3D had to do with Unity3D, I was a bit hesitant in trying it.

Anyways, I will try it as soon as I come home tonight.

[jacmoe]

Ogre: 10 minutes without unity build.
With unity build: 2m30s !

[bstone]

(Edit: Side note, at one stage I was doing an experiment mixing in Cube game code, and the compile time jumped to 6 minutes on my old rig. I just couldn't work like that, and don't really understand how people can function once compile times go over 30-40 seconds.)

Anything longer than 5 seconds of compile time and running tests combined hurts me. For really large projects I have to balance by keeping only a subset of test suites enabled during the dev cycles and/or having "lab" projects what I call them to keep it under 5 seconds. But I feel like paying for all my sins now with MSVC 2010 as it doesn't matter if it's a large project or a one liner. I almost switched back to MSVC 2008 at one point, but I love the C++xx features too much it seems.

And man, just try compiling some old code with MSVC 6 today. Now tell me about the need of SSD drives for any modern day development

[Kojack]

My best time for a unity build was ogremain in 41 seconds, down from 9min 44sec.

[syedhs]

Actually you don't need to add stdafx.h (or any precompile header) if you don't want to - and this is especially true for 3rd party libraries. Just right click the cpp files in questions, and then select Properties -> C/C++ -> Precompile Headers. Change the field accordingly

[mkultra333]

Ah, thanks for the tip, syedhs. I'll give that a shot.

Edit: Yes, that worked, I don't need to include stdafx.h in the recast files. It doesn't change one thing though, I have one class that uses Recast and another class that uses Ogre. Because both Recast and Ogre headers are in the stdafx.h for use as precompiled headers, now both the classes are including Recast AND Ogre, instead of just one or the other.

[jacmoe]

I usually use the CMake 'project' - don't know if it's up-to-date now as it's been a while since I checked it out.

[syedhs]

I really think that you don't need to include recast in precompiled header as only one class need recast, and probably hundred other classes don't need recast so it is a waste of hard disk space and compile speed. If I were you,
1) I will just add recast source files with no precompiled header option and then
2) the class which uses both recast and ogre to simply include recast header files just as normal.

If you noticed it, the only 'extra step' is to specify 'no precompiled header' for recast source C++ files and all others remain the same. And do not put recast header files into your precompiled header.