Build fix for Windows

Everything about development and the OpenMW source code.
garvek
Posts: 34
Joined: 03 Jun 2012, 21:20

Build fix for Windows

Post by garvek »

Hello all,

as I tried to build OpenMW under windows (Seven / Visual Studio 10), I encountered several little issues but was able to fix them. I list them here and hope it could help:

- Dependencies in CMake:
* use flag to enable AUDIERE and disable LIBSNDFILE. I didn't try to alter CMakeFiles.txt but rather used the command line (ie cmake ..\OpenMW-src -G "Visual Studio 10" -DUSE_MPG123=OFF -DUSE_AUDIERE=ON ).
* Boost from Ogre 1.8 doesn't work (under windows at least), I had to use the separate full Boost installation.

- Source code
* patch: I have fixed several issues related to C++ conformance (VS refused to build without them) and some evil Macro not cleaned when debug build is chosen. There was also some mistake in functions declaration which were also blocking for VC10. Finally I have fixed env variables and some paths.

Sorry in advance for posting them here but I prefered as 1st post not putting files as attachment (can be refused sometimes by admin rules).

apps/openmw/mwgui/settingswindow.hpp

Code: Select all

@@ -14,14 +14,15 @@ namespace MWGui
     {
         public:
             SettingsWindow(WindowManager& parWindowManager);
 
         private:
-            static const float sFovMin = 30;
-            static const float sFovMax = 140;
-            static const float sViewDistMin = 2000;
-            static const float sViewDistMax = 5600;
+			//PATCH GVK 2012-06-03: VC10 refuses float const initializers
+            static int const sFovMin = 30;
+            static int const sFovMax = 140;
+            static int const sViewDistMin = 2000;
+            static int const sViewDistMax = 5600;
 
         protected:
             MyGUI::Button* mOkButton;
 
             MyGUI::ScrollBar* mMenuTransparencySlider;
apps/openmw/mwsound/audiere_decoder.cpp

Code: Select all

@@ -39,12 +39,13 @@ class OgreFile : public audiere::File
     {
         return mStream->tell();
     }
 
     size_t refs;
-    virtual void ref() { ++refs; }
-    virtual void unref()
+	//PATCH GVK 2012-06-03 Fix call convention
+    ADR_METHOD(void) ref() { ++refs; }
+    ADR_METHOD(void) unref()
     {
         if(--refs == 0)
             delete this;
     }
 
cmake/FindBullet.cmake

Code: Select all

@@ -17,10 +17,13 @@
 #
 # Redistribution AND use is allowed according to the terms of the New
 # BSD license.
 # For details see the accompanying COPYING-CMAKE-SCRIPTS file.
 
+# Patch GVK 2012-06-03: Windows build support
+set(BULLET_ROOT $ENV{BULLET_ROOT})
+
 macro(_FIND_BULLET_LIBRARY _var)
   find_library(${_var}
      NAMES
         ${ARGN}
      PATHS
cmake/FindMyGUI.cmake

Code: Select all

@@ -33,11 +33,13 @@ NO_DEFAULT_PATH )
 find_path ( MYGUI_PLATFORM_INCLUDE_DIRS
 MyGUI_OgrePlatform.h
 "${MYGUISDK}/Platforms/Ogre/OgrePlatform/include"
 NO_DEFAULT_PATH )
 
-SET ( MYGUI_LIB_DIR ${MYGUISDK}/*/lib )
+# PATCH GVK 2012-06-03
+#SET ( MYGUI_LIB_DIR ${MYGUISDK}/*/lib )
+SET ( MYGUI_LIB_DIR ${MYGUISDK}/lib )
 
 find_library ( MYGUI_LIBRARIES_REL NAMES
 MyGUIEngine.lib
 MyGUI.OgrePlatform.lib
 HINTS
libs/openengine/bullet/pmove.cpp

Code: Select all

@@ -1831,17 +1831,17 @@ void PmoveSingle (playerMove* const pmove)
 
 	// End Aedra-specific code
 	pml.hasWater = pmove->hasWater;
 	pml.isInterior = pmove->isInterior;
 	pml.waterHeight = pmove->waterHeight;
-#ifdef _DEBUG
-	if (!pml.traceObj)
-		__debugbreak();
-
-	if (!pml.traceObj->incellptr)
-		__debugbreak();
-#endif
+//#ifdef _DEBUG
+	//if (!pml.traceObj)
+	//	__debugbreak();
+	//
+	//if (!pml.traceObj->incellptr)
+	//	__debugbreak();
+//#endif
 
 	// determine the time
 	pml.msec = pmove->cmd.serverTime - pm->ps.commandTime;
 	if ( pml.msec < 1 )
 		pml.msec = 1;

Regards
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: Build fix for Windows

Post by scrawl »

the fixes look reasonable. btw, the preferred (faster) way is if you fork openmw on github and make a pull request for these changes.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Build fix for Windows

Post by Zini »

The stuff about the float constants is an obvious fix. Everything else I would prefer to be tested at least by one of our Windows developers, before it is merged into the master branch.

As scrawl wrote, we prefer contributions to go through github. Normally we don't accept patched.

And please avoid this kind of lines:

Code: Select all

+   //PATCH GVK 2012-06-03 Fix call convention
We have a version control system that keeps track of who changed what and when. No point in littering the code with additional comments.
garvek
Posts: 34
Joined: 03 Jun 2012, 21:20

Re: Build fix for Windows

Post by garvek »

Ah OK, sorry for that. I should have cleaned up before submitting, I used these traces to track my changes internally. I should also have read the docs about the submit process. :oops:
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Build fix for Windows

Post by Zini »

Since these fixes are on github now, can we have at least one more Windows developer testing them, before I merge them into master?
garvek
Posts: 34
Joined: 03 Jun 2012, 21:20

Re: Build fix for Windows

Post by garvek »

I need to push the cleanup you suggested (removed commented variable + comment block), but it won't change the result normally.

BTW I think I'll take a look at precompiler headers because current generation takes ages ...
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Build fix for Windows

Post by Zini »

Really? Works okay-ish for me. Building isn't exactly lightning fast, but also not so slow that it is a problem.

There is still a large decoupling task on the tracker, that should reduce the build time significantly. It just doesn't have a high priority so far. Precompiled headers always sounded like more trouble than they are worth to me.
garvek
Posts: 34
Joined: 03 Jun 2012, 21:20

Re: Build fix for Windows

Post by garvek »

One you get the principle, they are rather easy to implement, and should not break the build. Anyway the decoupling task is more efficient, I agree on this point. Maybe I will switch to that, then. ^^
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Build fix for Windows

Post by Zini »

I didn't got around to writing it down in detail yet. Probably easier, if I do it myself than explaining it in enough detail (uses some techniques that are not widely known, I believe). If you can work with the slow building for a little longer I will add it to the roadmap for 0.17.0 (though there is always the chance to it gets pushed one release further down the roadmap, depending on my workload).
garvek
Posts: 34
Joined: 03 Jun 2012, 21:20

Re: Build fix for Windows

Post by garvek »

No problem :)
Post Reply