CMake and the Windows FreeOrion SDK

[adrian_broher]

Hello,

maybe you have seen the latest commits in the repository by me. Those are preparations to enable the generation of windows specific build systems like Visual Studio, nmake, msbuild and others. Now I hit a problem with the SDK we currently distribute to people, who want to develop on windows with VisualStudio 2010. CMake uses scripts, called find modules (FindBoost.cmake, …) to locate header files, libraries and executables. CMake distributes find modules for widely used libraries and those 'buildin' find modules expect the directory layout as the upstream library would install/distribute their sources. The affected libraries are python, where the include headers should be located in <root>/include/python2.7 not <root>/include/Python27 [1]; libpng headers, which should be located in <root>/include/ not <root>/include/png/ [2] ; zlib headers, which should be located in <root>/include/ not <root>/include/zlib/ [3]. Moving those headers and adding some missing bits that I have on my pc would allow to create other build systems files on windows.

[1] http://docs.python.org/2/c-api/intro.html#include-files
[2] http://www.libpng.org/pub/png/book/chap ... ch13.div.2
[3] http://www.zlib.net/zlib_how.html

[Geoff the Medio]

The affected libraries are python, where the include headers should be located in <root>/include/python2.7 not <root>/include/Python27 [1]; libpng headers, which should be located in <root>/include/ not <root>/include/png/ [2] ; zlib headers, which should be located in <root>/include/ not <root>/include/zlib/ [3].

I don't see any reason moving those would be a problem...

[adrian_broher]

So far the configuration and compiling of and from cmake generated Visual Studio projects works.

Currently known issues are:

• you need to set the build of freeorioncommon and freeorionparse to static libraries manually after each configuration.
• running the application doesn't work yet, because of the location of the dll inside the SDK/the binaries location after linking.
• The ogre configuration is not properly generated yet.

Except the first issue, which need some discussion about how we should link the libraries, none of those seem to be too hard to solve.

The following changes to the Windows SDK are required, all of them consist of moving the contents of the listed directories to the given directory:

• <root>/include/Python27 -> <root>/include/python2.7
• <root>/include/png/ -> <root>/include/
• <root>/include/zlib/ -> <root>/include/
• <root>/lib/bullet/ -> <root>/lib/

The attached patch contains updated in source Visual Studio solutions that respect the new search pathes (well, it's more a cleanup than anything else).

Also there was commit 6585 to smooth out some build inconsistencies across the build platforms. MSVC and XCode users maybe need to delete util/Version.cpp so it can be regenerated.

[Geoff the Medio]

The first point, about how to link the common and parse libraries, is not really a discussion of what we'd want to do, as we'd almost surely like to be linking them as DLLs. I recall there were problems such that this couldn't actually be done on windows, though...?

Also, note that regardless of whether the CMake generation of the MSVC build system gets working, I'm content to manually updake the MSVC 2010 solution, and have the XCode project continue to be manually updated. Requiring people to use CMake on Windows and OSX is an extra step I do not want to make required. I've aways found CMake to be horrendously un-user-friendly and annoying to use, and I've had to do so repeatedly.

Regarding the SDK changes, I'll ask Vezzra if he can do something about it...

[Vezzra]

Regarding the SDK changes, I'll ask Vezzra if he can do something about it...

I will, but not immediately. Will report back when I get to it.

[shawndream]

Also, note that regardless of whether the CMake generation of the MSVC build system gets working, I'm content to manually updake the MSVC 2010 solution, and have the XCode project continue to be manually updated. Requiring people to use CMake on Windows and OSX is an extra step I do not want to make required. I've aways found CMake to be horrendously un-user-friendly and annoying to use, and I've had to do so repeatedly.

I definitely appreciate that, I've never built anything the size of FO, (except many years ago where I used Gentoo for a work project which does a lot of recompiling) and I had next to no experience with SVN and MSVC... yet the process of downloading, updating and compiling free orion on windows was almost hiccup free for me.

Now one of these days I'll pull myself away from taking plugging towards my first win in FreeOrion to figure out why updating my patch to try and make autoseed randomization have a good user interface are failing, and repay that effort.

[adrian_broher]

The first point, about how to link the common and parse libraries, is not really a discussion of what we'd want to do, as we'd almost surely like to be linking them as DLLs. I recall there were problems such that this couldn't actually be done on windows, though...?

Suggestion is to build freeorionparse as static library and link it into freeorioncommon, which will build as shared library.

Patch attached

The patch don't handle any mac related stuff, because I don't have test platform available anytime soon. But Vezzra should be able to fix this by:

• removing the '-undefined dynamic_lookup' linker flag from the common project
• removing the freeorionparse.dylib library from freeorion{ca,d} as dependency
• removing the freeorionparse.dylib from the copy shared libraries target
• Change the freeorionparse target from a dynamic to a static library (see this so article)
• add freeorionparse.a as link dependency to freeorioncommon.dylib

yet the process of downloading, updating and compiling free orion on windows was almost hiccup free for me.

You seem to have great sense of humor. Preserve it while you're enjoying the general slowness of the solution and hitting the cl.exe segfaults and internal compiler errors when compiling first time the parser component.

[Geoff the Medio]

yet the process of downloading, updating and compiling free orion on windows was almost hiccup free for me.

You seem to have great sense of humor. Preserve it while you're enjoying the general slowness of the solution and hitting the cl.exe segfaults and internal compiler errors when compiling first time the parser component.

Since he claims to have already compiled FreeOrion without substantial problems, he was presumably able to compile the parser on the first try?

I rarely have issues building from a clean solution, including compiling the parsers.

[shawndream]

yet the process of downloading, updating and compiling free orion on windows was almost hiccup free for me.

You seem to have great sense of humor. Preserve it while you're enjoying the general slowness of the solution and hitting the cl.exe segfaults and internal compiler errors when compiling first time the parser component.

Seriously, besides needing to install a service pack for Visual Studio the solution compiled wthout issue (and it recompiles pretty quickly too, when I made a small patch with a couple pedia entries, and when I have tried various ways to make randomization of seed automatic nicely).

Haven't recompiled in the past couple weeks though. (Unwilling to risk my current game with incompatible new SVN AI code).

Windows 7 64 bit core i7 laptop

[adrian_broher]

I rarely have issues building from a clean solution, including compiling the parsers.

Yandonman has stated more than once that it doesn't work and it's even common for me since a few commits.

[Geoff the Medio]

I rarely have issues building from a clean solution, including compiling the parsers.

Yandonman has stated more than once that it doesn't work and it's even common for me since a few commits.

I don't dispute that compiling the parsers causes some people problems, but that doesn't mean it's a problem for everyone.

[Dilvish]

Haven't recompiled in the past couple weeks though. (Unwilling to risk my current game with incompatible new SVN AI code).

It's been a while back now that I discovered how customize the AI deserialization so that it *should* always be backwards compatible with old saved games. I have to remember to cover it each time I add new attributes to the AI, though, so it's possible I could temporarily overlook doing so. If you see the AI break upon loading an old savegame, please post right away, I should be able to get it straightened out.

That said, it's just been a week or 2 since some broader changes were made to various c++ classes, so those might still be a compatibility problem for that game.

[Geoff the Medio]

The patch don't handle any mac related stuff...

Is it safe to apply / commit without the proposed Mac adjustments being done and tested?

[adrian_broher]

Is it safe to apply / commit without the proposed Mac adjustments being done and tested?

I doubt that. I dropped the FO_PARSE_API export macro, which would be needed for the dynamic library variant of the parser component.

[Geoff the Medio]

With the patch applied, I'm getting a windows API error:

Code: Select all

..\..\util\Process.cpp(99): error C2664: 'CreateProcessW' : cannot convert parameter 1 from 'char *' to 'LPCWSTR'
          Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

This is coming from "CreateProcess" being defined as "CreateProcessW" in WinBase.h:

Code: Select all

#ifdef UNICODE
#define CreateProcess  CreateProcessW
#else
#define CreateProcess  CreateProcessA
#endif // !UNICODE

Not sure why it's giving an error for this now but not before the patch... I don't see UNICODE defines being changed.