CMake and the Windows FreeOrion SDK

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderators: Committer, Committer

Message
Author
User avatar
adrian_broher
Programmer
Posts: 1082
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

CMake and the Windows FreeOrion SDK

#1 Post by adrian_broher » Thu Dec 19, 2013 3:48 pm

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
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12469
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: CMake and the Windows FreeOrion SDK

#2 Post by Geoff the Medio » Sat Dec 21, 2013 10:21 pm

adrian_broher wrote: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...

User avatar
adrian_broher
Programmer
Posts: 1082
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: CMake and the Windows FreeOrion SDK

#3 Post by adrian_broher » Thu Dec 26, 2013 9:26 pm

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.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12469
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: CMake and the Windows FreeOrion SDK

#4 Post by Geoff the Medio » Sun Dec 29, 2013 2:00 am

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...

User avatar
Vezzra
Release Manager, Design
Posts: 5028
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: CMake and the Windows FreeOrion SDK

#5 Post by Vezzra » Sun Dec 29, 2013 8:59 pm

Geoff the Medio wrote: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
Space Kraken
Posts: 124
Joined: Fri Nov 22, 2013 8:47 pm

Re: CMake and the Windows FreeOrion SDK

#6 Post by shawndream » Tue Dec 31, 2013 5:08 pm

Geoff the Medio wrote: 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. :)
Everything I post is self-created unless noted otherwise. It is simultaneously released under GPL 2.0 or later, CC Attribution-Share Alike 3.0, and GNU Free Documentation 1.2. Make something awesome with it please!

User avatar
adrian_broher
Programmer
Posts: 1082
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: CMake and the Windows FreeOrion SDK

#7 Post by adrian_broher » Fri Jan 17, 2014 10:15 pm

Geoff the Medio wrote: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
shawndream wrote: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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12469
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: CMake and the Windows FreeOrion SDK

#8 Post by Geoff the Medio » Fri Jan 17, 2014 10:21 pm

adrian_broher wrote:
shawndream wrote: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
Space Kraken
Posts: 124
Joined: Fri Nov 22, 2013 8:47 pm

Re: CMake and the Windows FreeOrion SDK

#9 Post by shawndream » Fri Jan 17, 2014 10:25 pm

adrian_broher wrote:
shawndream wrote: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
Everything I post is self-created unless noted otherwise. It is simultaneously released under GPL 2.0 or later, CC Attribution-Share Alike 3.0, and GNU Free Documentation 1.2. Make something awesome with it please!

User avatar
adrian_broher
Programmer
Posts: 1082
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: CMake and the Windows FreeOrion SDK

#10 Post by adrian_broher » Fri Jan 17, 2014 10:27 pm

Geoff the Medio wrote: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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12469
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: CMake and the Windows FreeOrion SDK

#11 Post by Geoff the Medio » Fri Jan 17, 2014 10:31 pm

adrian_broher wrote:
Geoff the Medio wrote: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.

User avatar
Dilvish
AI Lead, Programmer
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: CMake and the Windows FreeOrion SDK

#12 Post by Dilvish » Fri Jan 17, 2014 10:41 pm

shawndream wrote: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.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12469
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: CMake and the Windows FreeOrion SDK

#13 Post by Geoff the Medio » Sat Jan 18, 2014 6:32 am

adrian_broher wrote:The patch don't handle any mac related stuff...
Is it safe to apply / commit without the proposed Mac adjustments being done and tested?

User avatar
adrian_broher
Programmer
Posts: 1082
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: CMake and the Windows FreeOrion SDK

#14 Post by adrian_broher » Sat Jan 18, 2014 8:17 am

Geoff the Medio wrote: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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12469
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: CMake and the Windows FreeOrion SDK

#15 Post by Geoff the Medio » Sat Jan 18, 2014 6:32 pm

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.

Post Reply