Windows compilation flags - part 1: activating /O2

[Neo2003]

Hello,

It's a very simple patch only for Windows users.

Nearly all projects miss the optimization flag, that is one a the reason that makes mangos run faster on Linux since on Linux who would compile something without /O2 ?

Then this patch activate /O2 for both w32/release and x64/release for all projects where it was missing.

The gray display in Visual Studio for a setting that not mean it's activated, this means it's not configured and what is displayed does not reflect what is used by the compiler. Just check the command line arguments passed to CL and see that most of the projects don't pass any optimization = no optimization.

Check this patch, if no objections this will go in GIT soon since it's a very basic minimal optimization.

http://pastebin.com/incNzHJ5

Note: I also took the opportunity to align VC80 configuration with VC90 one (removing x64 portability check)

[VladimirMangos]

For release, or you add for debug version also?

[added]Oh, sorry, i see you already answer to this question in post ^^

[zergtmn]

Optimization is enabled by default in Release build.

VC 10.0 uses MSBuild system so all default settings are stored in *.props files contained in folder c:\\Program Files\\MSBuild\\Microsoft.Cpp\\v4.0\\

Let's look at Microsoft.Cpp.props. It is attached to all C++ projects via the following

<Import Project="$(VCTargetsPath)\\Microsoft.Cpp.props" />

For debug build:

 <ItemDefinitionGroup Condition="'$(UseDebugLibraries)' == 'true'">
   <ClCompile>

     <Optimization                     Condition="'%(ClCompile.Optimization)'                  == ''">Disabled</Optimization>

   </ClCompile>
 </ItemDefinitionGroup>

UseDebugLibraries is defined in project file to true or false, depending on configuration.

"Optimization" is set to Disabled only if ClCompile.Optimization was not overridden before (equals ' ').

For release build:

  <ItemDefinitionGroup>
   <ClCompile>

     <Optimization                     Condition="'%(ClCompile.Optimization)'                  == '' and
                                                  ('%(ClCompile.BasicRuntimeChecks)'           == '' or
                                                  '%(ClCompile.BasicRuntimeChecks)'            == 'Default')">MaxSpeed</Optimization>

   </ClCompile>
 </ItemDefinitionGroup>

ItemDefinitionGroup tag has no 'Condition' attribute so this section is used always. "Optimization" is set to MaxSpeed if it is not overridden and BasicRuntimeChecks is set to default value.

Just check the command line arguments passed to CL and see that most of the projects don't pass any optimization = no optimization.

I have /O2 option in command line:

/I"..\\..\\dep\\include" /I"..\\..\\src\\framework" /I"..\\..\\src\\shared" /I"..\\..\\src\\game\\vmap" /I"..\\..\\dep\\ACE_wrappers" /I"..\\..\\dep\\include\\g3dlite" /Zi /nologo /W3 /WX- /O2 /Ob1 /D "WIN32" /D "NDEBUG" /D "_LIB" /D "_MBCS" /GF /Gm- /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /GR /Yu"pchdef.h" /Fp".\\game__x64_Release\\game.pch" /Fa".\\game__x64_Release\\" /Fo".\\game__x64_Release\\" /Fd".\\game__x64_Release\\" /Gd /FI"pchdef.h" /errorReport:queue 

[shauren]

that... or ditch the current build files and use cmake, this way you will only have to maintain one set of buildfiles and it will support all compilers cmake supports

[Neo2003]

Optimization is enabled by default in Release build.

VC 10.0 uses MSBuild system so all default settings are stored in *.props files contained in folder c:\\Program Files\\MSBuild\\Microsoft.Cpp\\v4.0\\

Thank you for this clarification around VC100. You are right, /O2 is set by default on this one. I did not see this since I don't have it installed on my PC at work. Anyway, it's not bad to have the settings set in project properties. This will align it with VC80 and VC90 ones even if this does not change the result.

For VC80 and VC90 this flag is not set by default and the interface is misleading everyone since it displays random values when settings are not set. (For example I spent a long time searching why a daemon I write next to mangos to communicate with it did crash, it was just the call convention displayed gray as "__cdecl" while it was not.).

I still believe this patch is fine like it is.

Neo2003

[VladimirMangos]

that... or ditch the current build files and use cmake, this way you will only have to maintain one set of buildfiles and it will support all compilers cmake supports

https://github.com/cipherCOM/mangos/tree/cmake-0.12

cipherCOM mostly complete cmake use for mangos build. But small still existed problem/limitations not let yet switch to it use currently. Release mode look like complete. Problems related to debug from IDE mostly.