CMake and the Windows FreeOrion SDK

[Geoff the Medio]

Any progress on this? / Bump

[adrian_broher]

The parsers are in a separate project in the MSVC project mainly to allow different compile settings, but if it works fine on OSX, is there any reason they need to be built separately, rather than right into the common library?

My goal is to unify the differences between the build systems, not to introduce new ones.

Any progress on this? / Bump

No, I haven't asked the guy, who offered me to grab the Xcode SDK for me, yet.

[JdH]

I'm not happy with the current import/export relationships.

1. There is a cyclic dependency between common and parser. As already mentioned here: Why not build only one common dynamic lib? If you need parser you'll need common. And if you need certain common functions you'll end up needing parser too.

2. There seems to be a mixture between imported/exported classes and in header defined methods (of exported classes). On the first glimpse, there seems not to be any clear structure in when and for what headers are used.
Many global vars are just declared on multiple points in code. And to make it really worse, they are sometimes marked as imported/exported and the other times not (in the same project!).

I don't know how the linux and Xcode compilers handle this mess (they seem to be able to compile and link this mess into dynamic libraries). Visual Studio seems to be more strict in the usage (or perhaps there is a linker flag I don't know about to achieve similar results).

Whatever we plan to do: I vote to get rid of mutual imports/export relationships, even though we could setup VC++ to link those (we would need an extra build step to create the import library of either parser or common first).

[Geoff the Medio]

Why not build only one common dynamic lib?

Mainly because compiling the parsers causes many compilers to implode, and different build settings are required just for the parsers project, but not the common project.

[adrian_broher]

Mainly because compiling the parsers causes many compilers to implode, and different build settings are required just for the parsers project, but not the common project.

If 'many compilers' stands for 'compilers delivered with visual studio {year}' than it's true. :o)

On a more serious note: While this not the best solution with the circular dependencies it's a lot better than it was a year ago. Here are some stories from the archive:

viewtopic.php?f=9&t=7564
viewtopic.php?f=9&t=7567
viewtopic.php?f=9&t=7581
viewtopic.php?f=9&t=7587
viewtopic.php?f=9&t=8740

[JdH]

Why not build only one common dynamic lib?

Mainly because compiling the parsers causes many compilers to implode, and different build settings are required just for the parsers project, but not the common project.

What about moving the needed definitions from common to parser then, to avoid cross references?

[Geoff the Medio]

What about moving the needed definitions from common to parser then, to avoid cross references?

Not sure exactly what you mean. Specific example or patch?

If 'many compilers' stands for 'compilers delivered with visual studio {year}' than it's true. )

Also reportedly on some Linux architectures: viewtopic.php?p=71702#p71702

[JdH]

I made some progress.
In my current setup parser is a static link library, common is a dll. The 3 executables only reference the common import lib (the other projects don't matter for the purpose discussed).

The compiled sizes are about 8 MB for the common.dll and about 2 MB for each executable.

I messed something up with the ValueRef-Classes though. Starting a game is currently resulting in an std::runtime_error: ValueRef evaluated with an unknown or invalid OpType.

[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'm currently uploading a partial draft new Windows MSVC 2010 SDK that has those include files moved. It also removes the Ogre/plugins/bullet stuff, and adds SDL2. Could you have a look and see if things are in the required places? Should appear at: https://sourceforge.net/projects/freeor ... 0SDK/Test/

[JdH]

I've got a working dll solution for windows up and running:
https://github.com/J-d-H/freeorion/tree/win-common.dll

I'm pretty sure CMake and XCode are gone for good...

[Dilvish]

I'm pretty sure CMake and XCode are gone for good...

What do you mean by that?

[JdH]

Well, I had to do some mayor changes and code rearrangements. I tried to change CMake and XCode configurations too, but have neither the proper test environments at the moment nor the necessary knowledge to update them without trial and error.

[adrian_broher]

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'm currently uploading a partial draft new Windows MSVC 2010 SDK that has those include files moved. It also removes the Ogre/plugins/bullet stuff, and adds SDL2. Could you have a look and see if things are in the required places? Should appear at: https://sourceforge.net/projects/freeor ... 0SDK/Test/

Haven't compiled it completely because it takes ages and the compile chokes as usual, but so far this package looks very good. The configuration pass works out of the box and finds all dependencies after

* Removing dependencies related to Ogre
* Adding a FindSDL2 search module to find the SDL2 related libraries

I will report the result when the compile is complete.

[Geoff the Medio]

I will report the result when the compile is complete.

Currently it probably won't compile due to a change in the limits on the number of parameters that can be passed to a single Boost Phoenix action. Numerous content bit parsers use 10 or more parameters, and the limit seems to be 9 now. I'm in the midst of rewriting the relevant parsers and content type constructors to wrap some of the parameters into helper structs.

Edit: Latest SVN (in the SDL SDK branch) parsers might build with Boost 1.56.

[Geoff the Medio]

I've got a working dll solution for windows up and running:

This might get some attention after the current work on updating the SDK / SDL transition is done.

However, if it's to get attention from me, I'll neen SVN patches, not git diffs. See the various threads discussing this.

That said, it'll need to not break other OS builds, so attention for people besides me would be needed first.