Build errors: precompiled headers, boost, /fp:fast, NMake

Environment:
MyGUI 3.2.0
Ogre SDK 1.8.1
VS 2010
CMake 2.8.9

Initial configure (cmake-gui):
I'm using the Ogre SDK. When I first configure CMake, it says it found freetype, Ogre and Doxygen. SVN_EXECUTABLE is not found. OGRE_BUILD and OGRE_SOURCE are empty.

Precompiled headers:
When I run NMake on this, it fails immediately on MyGUI_Button.cpp saying it cannot open precompiled header "MyGUI_Precompiled.pch". A solution on the forums is to run NMake with /i to ignore errors. This results in NMake eventually making its way to the "precompiled" headers and compiling them.

Boost:
When I run NMake again without ignoring errors, it gets to about 30% and then fails on MyGUI_OgreDataManager.cpp, saying it cannot open file "boost/thread/tss.hpp". The Compilation Instructions say to manually set BOOST_ROOT if Ogre was built with Boost. I add a BOOST_ROOT entry to the configuration and point it to the boost folder inside the Ogre SDK folder (path\OgreSDK_vc10_v1-8-1\boost). But when I generate, CMake gives a warning that the manually-specified variable was not used by the project. Sure enough, NMake still fails at the same place.

On a whim, I download the Ogre 1.8.1 source (note that I did NOT compile Ogre from source). I point OGRE_SOURCE to the folder and hit configure. Three new entries appear in the CMake configuration: BOOST_ROOT, Boost_DIR, and Boost_LIB_DIAGNOSTIC_DEFINITIONS. I once again point BOOST_ROOT to the boost folder inside the Ogre SDK (path\OgreSDK_vc10_v1-8-1\boost), configure and generate. There are lots of warnings of type C4193 and C4275. However, the next error is NOT related to Boost.

Error RC1103: invalid option, /fp:fast
/fp:fast is definitely an option in Visual Studio under Code Generation, so I don't know what this is about. If I turn off Demos and Tools in the CMake config, compilation goes to completion and the lib and dll files are created.

Visual Studio 2010:
So I decide to make a new build directory and I tell CMake to create a Visual Studio 10 project instead of NMake. I again have failed builds, but not related to precompiled headers. Once I employ the Boost solution above, the builds go fine, along with the Demos and Tools.

Conclusions:
So I just wanted to tell my little story here in the hopes that others trying to compile MyGUI might have an easier time. I also hope the creators of MyGUI might be able to tweak the CMake settings and the Compilation Instructions to avoid these problems in the future.

Also, it might be a good idea to simply make an SDK with working libs and dlls of MyGUI 3.2.0 for Ogre 1.8.1. Over the years, I've found there is no better way than building libraries from source yourself to guarantee the introduction of subtle errors and doubt.

Error RC1103: invalid option, /fp:fast
/fp:fast is definitely an option in Visual Studio under Code Generation, so I don't know what this is about. If I turn off Demos and Tools in the CMake config, compilation goes to completion and the lib and dll files are created.Removed this option, since it is not necessary anyway.
Visual Studio 2010:
So I decide to make a new build directory and I tell CMake to create a Visual Studio 10 project instead of NMake. I again have failed builds, but not related to precompiled headers. Once I employ the Boost solution above, the builds go fine, along with the Demos and Tools. I don't get it. Did you used same BOOST_ROOT option, that didn't helped in case of NMake build?
Also, it might be a good idea to simply make an SDK with working libs and dlls of MyGUI 3.2.0 for Ogre 1.8.1. Over the years, I've found there is no better way than building libraries from source yourself to guarantee the introduction of subtle errors and doubt.Well, that might be slightly better for users, but it's a pain for developers, since users will request SDK for various IDE's and various versions (only visual studio have 2005/2008/2010/2010SP1/2012/2012SP1/2012SP2), then you need to multiply this on various Ogre's versions users use MyGUI with. Oh, and don't forget that there are same Ogre version with various options such as threading and allocator.

Visual Studio 2010:
So I decide to make a new build directory and I tell CMake to create a Visual Studio 10 project instead of NMake. I again have failed builds, but not related to precompiled headers. Once I employ the Boost solution above, the builds go fine, along with the Demos and Tools. I don't get it. Did you used same BOOST_ROOT option, that didn't helped in case of NMake build?
Manually specifying the value of the BOOST_ROOT variable does work. However, I must first set the value of OGRE_SOURCE which makes the variable BOOST_ROOT and others appear. If I just create the BOOST_ROOT variable myself, it is ignored. Here's what I said before:


Boost:
When I run NMake again without ignoring errors, it gets to about 30% and then fails on MyGUI_OgreDataManager.cpp, saying it cannot open file "boost/thread/tss.hpp". The Compilation Instructions say to manually set BOOST_ROOT if Ogre was built with Boost. I add a BOOST_ROOT entry to the configuration and point it to the boost folder inside the Ogre SDK folder (path\OgreSDK_vc10_v1-8-1\boost). But when I generate, CMake gives a warning that the manually-specified variable was not used by the project. Sure enough, NMake still fails at the same place.

On a whim, I download the Ogre 1.8.1 source (note that I did NOT compile the Ogre source). I point OGRE_SOURCE to the folder and hit configure. Three new entries appear in the CMake configuration: BOOST_ROOT, Boost_DIR, and Boost_LIB_DIAGNOSTIC_DEFINITIONS. I once again point BOOST_ROOT to the boost folder inside the Ogre SDK (path\OgreSDK_vc10_v1-8-1\boost), configure and generate. There are lots of warnings of type C4193 and C4275. However, the next error is NOT related to Boost.


Also, it might be a good idea to simply make an SDK with working libs and dlls of MyGUI 3.2.0 for Ogre 1.8.1. Over the years, I've found there is no better way than building libraries from source yourself to guarantee the introduction of subtle errors and doubt.Well, that might be slightly better for users, but it's a pain for developers, since users will request SDK for various IDE's and various versions (only visual studio have 2005/2008/2010/2010SP1/2012/2012SP1/2012SP2), then you need to multiply this on various Ogre's versions users use MyGUI with. Oh, and don't forget that there are same Ogre version with various options such as threading and allocator.
Well I was thinking of only having a MyGUI SDK to go along with the current Ogre SDKs. So if people compile Ogre themselves with all different options or want to use an unstable version like 1.9, then they'd be expected to compile MyGUI themselves as well. But if they just want to use the current Ogre 1.8.1 SDK, then there's a MyGUI SDK for them as well.

That cuts that work down a lot, but yes, I understand that it still leaves five versions you guys have to support: VS2010, VS2008, MinGW, Mac OS X, and iOS.

That cuts that work down a lot, but yes, I understand that it still leaves five versions you guys have to support: VS2010, VS2008, MinGW, Mac OS X, and iOS.What is also important, that all those versions need to be updated with each new Ogre release. Also looking at upcoming Ogre 1.9 release and there are 10 SDK versions total (64 bit versions, Android and WinRT were added).
Just saying. I agree that SDK would be way better for new users, but unfortunately it also would be too hard for as us well.

Ok, the SDK was just a suggestion.

Did my reply about the Boost fix make sense? It just seems like the Cmake project assumes users are compiling Ogre from source. But if users are using the Ogre SDK, they're forced to download the Ogre source anyway and manually point the Cmake project to it, and also manually point the BOOST_ROOT variable to the SDK's version.

I fixed wiki page, so that user need to fill BOOST_ROOT option, but not add it.
Also this won't be necessary for most users, since I also changed CMake code to add boost from OgreSDK automatically.