CMake and the Windows FreeOrion SDK
Moderator: Committer
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
CMake and the Windows FreeOrion SDK
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
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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: CMake and the Windows FreeOrion SDK
I don't see any reason moving those would be a problem...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].
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: CMake and the Windows FreeOrion SDK
So far the configuration and compiling of and from cmake generated Visual Studio projects works.
Currently known issues are:
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:
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.
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.
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/
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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: CMake and the Windows FreeOrion SDK
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...
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...
Re: CMake and the Windows FreeOrion SDK
I will, but not immediately. Will report back when I get to it.Geoff the Medio wrote:Regarding the SDK changes, I'll ask Vezzra if he can do something about it...
-
- Space Kraken
- Posts: 124
- Joined: Fri Nov 22, 2013 8:47 pm
Re: CMake and the Windows FreeOrion SDK
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.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.
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!
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: CMake and the Windows FreeOrion SDK
Suggestion is to build freeorionparse as static library and link it into freeorioncommon, which will build as shared library. 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: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...?
- 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
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.shawndream wrote:yet the process of downloading, updating and compiling free orion on windows was almost hiccup free for me.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: CMake and the Windows FreeOrion SDK
Since he claims to have already compiled FreeOrion without substantial problems, he was presumably able to compile the parser on the first try?adrian_broher wrote: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.shawndream wrote:yet the process of downloading, updating and compiling free orion on windows was almost hiccup free for me.
I rarely have issues building from a clean solution, including compiling the parsers.
-
- Space Kraken
- Posts: 124
- Joined: Fri Nov 22, 2013 8:47 pm
Re: CMake and the Windows FreeOrion SDK
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).adrian_broher wrote: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.shawndream wrote:yet the process of downloading, updating and compiling free orion on windows was almost hiccup free for me.
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!
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: CMake and the Windows FreeOrion SDK
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 wrote:I rarely have issues building from a clean solution, including compiling the parsers.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: CMake and the Windows FreeOrion SDK
I don't dispute that compiling the parsers causes some people problems, but that doesn't mean it's a problem for everyone.adrian_broher wrote: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 wrote:I rarely have issues building from a clean solution, including compiling the parsers.
Re: CMake and the Windows FreeOrion SDK
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.shawndream wrote:Haven't recompiled in the past couple weeks though. (Unwilling to risk my current game with incompatible new SVN AI code).
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
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: CMake and the Windows FreeOrion SDK
Is it safe to apply / commit without the proposed Mac adjustments being done and tested?adrian_broher wrote:The patch don't handle any mac related stuff...
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: CMake and the Windows FreeOrion SDK
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 wrote:Is it safe to apply / commit without the proposed Mac adjustments being done and tested?
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: CMake and the Windows FreeOrion SDK
With the patch applied, I'm getting a windows API error:
This is coming from "CreateProcess" being defined as "CreateProcessW" in WinBase.h:
Not sure why it's giving an error for this now but not before the patch... I don't see UNICODE defines being changed.
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
Code: Select all
#ifdef UNICODE
#define CreateProcess CreateProcessW
#else
#define CreateProcess CreateProcessA
#endif // !UNICODE