CMake and the Windows FreeOrion SDK

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

Moderator: Committer

Message
Author
JdH
Space Floater
Posts: 30
Joined: Mon Sep 01, 2014 11:09 am

Re: CMake and the Windows FreeOrion SDK

#46 Post by JdH »

Geoff the Medio wrote:
JdH wrote: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.
I had setup a linux vm. And tried some fixes for my working win version, but all produces very bloated output (>100 MB freeorioncommon.so).
But compiling trunk produces 20 MB and 10 MB binaries on that ubuntu vm (@real linux users: how large are your binaries?). Only mac with xcode seems to produce reasonable small binaries.

I already investigated some other approaches, but I think if we want to fix it and keep troubles away we need to refactor the code and split it in a cleaner way. There are many header files mixed up with classes and functions to be exported and others to be used internally.
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
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: CMake and the Windows FreeOrion SDK

#47 Post by Dilvish »

JdH wrote:But compiling trunk produces 20 MB and 10 MB binaries on that ubuntu vm (@real linux users: how large are your binaries?).
for me on Ubuntu libfreeorioncommon.so is 9MB and libfreeorionparse.so is 5.3MB, and the human client, AI client, and server are 6.5MB, 2.8MB, and 3.1 MB respectively. But that's compiling 'Release' which does more optimization and I think drops a lot of debugging info; the default build (on Linux at least) seems to be Debug
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

JdH
Space Floater
Posts: 30
Joined: Mon Sep 01, 2014 11:09 am

Re: CMake and the Windows FreeOrion SDK

#48 Post by JdH »

I'm not sure how to change to Release mode on linux.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Chriss
Dyson Forest
Posts: 231
Joined: Sun May 11, 2008 10:50 am

Re: CMake and the Windows FreeOrion SDK

#49 Post by Chriss »

Code: Select all

-rwxr-xr-x 1 chris chris  24M  3. Sep 22:54 freeorion
-rwxr-xr-x 1 chris chris 9,2M  3. Sep 22:41 freeorionca
-rwxr-xr-x 1 chris chris  11M  3. Sep 22:41 freeoriond
-rwxr-xr-x 1 chris chris  27M  3. Sep 22:40 libfreeorioncommon.so
-rwxr-xr-x 1 chris chris 5,5M  1. Sep 20:20 libfreeorionparse.so
-rwxr-xr-x 1 chris chris 798K  3. Sep 22:44 libGiGiOgrePlugin_OIS.so
-rwxr-xr-x 1 chris chris 779K  3. Sep 22:44 libGiGiOgre.so
-rwxr-xr-x 1 chris chris  16M  3. Sep 22:44 libGiGi.so
SVN Rev 7692 on Arch Linux.

About Release: Edit CMakeLists.txt I guess:

Code: Select all

set(FREEORION_RELEASE false)
Attached patches are released under GPL 2.0 or later.

User avatar
vincele
Space Dragon
Posts: 341
Joined: Sun Mar 23, 2014 6:10 pm

Re: CMake and the Windows FreeOrion SDK

#50 Post by vincele »

Chriss wrote:About Release: Edit CMakeLists.txt I guess:

Code: Select all

set(FREEORION_RELEASE false)
Or use a cmake command-line argument

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Debug
or

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Release
All the patches I'll provide for freeorion will be released under the GPL v2 or later license.
Let's unleash the dyson forest powa!

JdH
Space Floater
Posts: 30
Joined: Mon Sep 01, 2014 11:09 am

Re: CMake and the Windows FreeOrion SDK

#51 Post by JdH »

Ok, compiled linux with release mode, and it looks now more reasonable. But still a lot larger than my windows compilations (missing optimization flags in our cmake files?).

I also managed to create patches (at least I hope) without FreeOrion in path.
Either someone tells me how I can easily work with (and create my own) branches in svn or someone has to tell me, how I can easily create git patches with the FreeOrion directory stripped away (or you could all checkout svn trunk without skipping the FreeOrion directory). I'm a bit at a loss working with svn.
Attachments

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

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

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
vincele
Space Dragon
Posts: 341
Joined: Sun Mar 23, 2014 6:10 pm

Re: CMake and the Windows FreeOrion SDK

#52 Post by vincele »

JdH wrote:Ok, compiled linux with release mode, and it looks now more reasonable. But still a lot larger than my windows compilations (missing optimization flags in our cmake files?).

I also managed to create patches (at least I hope) without FreeOrion in path.
Either someone tells me how I can easily work with (and create my own) branches in svn or someone has to tell me, how I can easily create git patches with the FreeOrion directory stripped away (or you could all checkout svn trunk without skipping the FreeOrion directory). I'm a bit at a loss working with svn.
You may have a look at Dilvish's suggestion from this post

I've just given a very quick look at your patch, It's too huge for me, sorry. I prefer a pile of small patches that do only one single thing and which still let the codebase compile at each step. Even if you'll modify the same file in multiple patches. That makes the whole lot easier to review and/or accept. It also allows bissection testing to find regressions...

You can try to set -O2 vs -Os compiler options, and look if something change without anything breaking...
All the patches I'll provide for freeorion will be released under the GPL v2 or later license.
Let's unleash the dyson forest powa!

JdH
Space Floater
Posts: 30
Joined: Mon Sep 01, 2014 11:09 am

Re: CMake and the Windows FreeOrion SDK

#53 Post by JdH »

Well, the patch is huge, because I needed to change many things to get it compiled for windows vc2010 and linux with cmake.

Perhaps we could reduce or split the changes and changing the projects at the last step. This way we maybe able to change one file a time. But I guess you primarily mean the changes put into ValueRef.h and ValueRef.cpp. If we want to (or have to for what ever reason) split those changes into multiple steps, we should separate the different classes into separate files at the same time...
But I won't put any additional effort into it, until not someone confirms, that it is working on other platforms than windows. No need to put additional time into it, if it still has mayor flaws.
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
vincele
Space Dragon
Posts: 341
Joined: Sun Mar 23, 2014 6:10 pm

Re: CMake and the Windows FreeOrion SDK

#54 Post by vincele »

JdH wrote:This way we maybe able to change one file a time. But I guess you primarily mean the changes put into ValueRef.h and ValueRef.cpp. [...] we should separate the different classes into separate files at the same time...
It's not quite the one-file-at-a-time, or all class splitting. It's one-single-logical-change per patch:

- split one class from a file into its own file(s)
- rename a file / class
- fix some (or all) whitespace in a file
- fix comments
- fix a bug
etc..

Please don't mix whitespace or other small changes in file renames or class split, it's better done as a separate patch either before or afterwards. Code move patches should be just that, nothing else in the mix.

This is not only good for code reviews, but also for debugging and merging concurrent modifications. With a huge patch you'll perhaps never have a single real review, but by splitting you'll get the non controversial parts in easier / sooner, because they become obvious patches. And that will ease the discussion about the remaining ones. That should also help Geoff or the people committing the patches to svn, if it's easier for them, everyone wins.

This is not meant to be a lecture on dev, only a hint if you want some reviews from me...

Wrt SCMs, I personally I use quilt inside my local svn copy to manage the patch stack, it's quite easy. I only use svn to update from upstream.

Edi:t I can try to help with test-compiling under linux (debian x86-64)
All the patches I'll provide for freeorion will be released under the GPL v2 or later license.
Let's unleash the dyson forest powa!

JdH
Space Floater
Posts: 30
Joined: Mon Sep 01, 2014 11:09 am

Re: CMake and the Windows FreeOrion SDK

#55 Post by JdH »

Ok, I have reviewed my patches. Seems like there slipped some auto correction through while editing some files.
There is only one rename in this patch, and that does nothing else (no whitespace changes etc., except the vc solution change maybe, would have to check that).
There are a few whitespace changes we cold get rid off, that occurred while adding an additional namespace.
That would still leave a pretty huge patch.

I will make these changes to my patches, if some linux user confirms, that the game is still working with my patches applied. If not perhaps some changes aren't needed and would leave me with useless doubled work.

PS: And I can split the code movements from ValueRef in seperate patches.
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: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: CMake and the Windows FreeOrion SDK

#56 Post by Geoff the Medio »

What is the purpose of renaming Parse.cpp to ParseImpl.cpp?

JdH
Space Floater
Posts: 30
Joined: Mon Sep 01, 2014 11:09 am

Re: CMake and the Windows FreeOrion SDK

#57 Post by JdH »

To avoid the mutual dependency problem for vc the parse-project is a static lib imported by the common project, which compiles into a dynamic lib.
Since I do neither know nor find a way to export functions from a static lib I had to move the exports from parse to the common project.
To avoid having to dig deep into the parser code and make other error prone changes there (I have seen the use of some static vars in nameless namespaces) I had to move the current implementation to a different namespace and "proxy" the parse functions inside the common.dll.
The new parse.cpp (in correlation with the nearly unchanged parse.h to avoid needing to update imports everywhere) contains the implementation for common to export (just calling the old functions inside the new namespace).
I decided to move the current content of parse.cpp to parseImpl.cpp and then merge the modified parse.h content to the existing parseImpl.h.
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
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: CMake and the Windows FreeOrion SDK

#58 Post by Dilvish »

I just tested these patches with a cmake build on Ubuntu Linux, with Boost 1.53; it compiled fine and appeared to run fine for the handful of turns I tested it.
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
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: CMake and the Windows FreeOrion SDK

#59 Post by adrian_broher »

I had a better solution available but thanks to the hdd crash I'm currently not able to look up how it was done exactly.

You can look up the usage of the pragma directive to declare external symbols for the linker.

IIRC i used this: http://msdn.microsoft.com/de-de/library/7f0aews7.aspx

With only 6 or so symbols needed this is far less intrusive than what you provide here.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

JdH
Space Floater
Posts: 30
Joined: Mon Sep 01, 2014 11:09 am

Re: CMake and the Windows FreeOrion SDK

#60 Post by JdH »

adrian_broher wrote:With only 6 or so symbols needed this is far less intrusive than what you provide here.
Well, maybe. But I'm also not happy how the code divides over the projects right now.
I guess we could skip a huge amount of my changes, and it would still work. But: Some classes are exported/imported, and others classes are just inlined, or skipped entirely in the same header files. I have not looked deep into the executable code, but it seems to me, that sometimes one would love to use a certain function or class, and it won't work out of the box, because that class/function isn't exported, even though other classes/functions from the same header are...
That's why I tried to just export everything from a header that already exports something.

Maybe it would be easier and cleaner to list all the functionality needed cross executables and design an proper api to excess those.

Maybe it is just me who thinks the current state of parser/common/executable-projects separation is a huge error prone mess.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply