CMake and the Windows FreeOrion SDK

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

Moderator: Committer

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

Re: CMake and the Windows FreeOrion SDK

#61 Post by adrian_broher »

JdH wrote: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.
This is intentional. No need to export what is not used outside of the library. Every exported symbol increases dynamic linking time and the processing time during the linker stage (and yes this does matter, see further below). Also the size of the binary increases because every exported symbol is stored in the symbol table making the installer bigger.
JdH wrote: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...
And your point is? When you need a symbol then export it. If you don't need it you don't export it. No need to bloat the binaries and making linking harder than it already is.
JdH wrote:Maybe it would be easier and cleaner to list all the functionality needed cross executables and design an proper api to excess those.
No proper api can declare away the dependency of the common on parser and parser on common. We need to call the parser from within common, the parsers needs to call some domain specific functions. This can't be changed.

The reason why the parser library exists was already explained. The parser lib needs different compiler settings than the common lib because otherwise neither the linker nor the compiler could handle the compile process thanks to a compiler/linker limitation [1]. It would be possible to maintain the compiler setting on a per file basis but that is useless work because it doesn't solve the issue of linking and just add unnecessary burden of maintenance.

So what other possibilities do we have?

1) we split up common into a 'very common' and 'not so common' library. 'very common' contains only the code that parse and 'not so common' need but itself shouldn't of course need any symbols from 'not so common' and 'parse'. Great, now we have moved the circular dependency to the linking stage and if we're lucky we don't have duplicate symbols from linking to 'very common' when we meld together the static 'very common', static 'not so common' and static 'parse' into a dynamic 'common'.

2) Tell the linker that there will some symbols from parse available in the future step that he needs now to link the code of common. This can be done by a map file, a stub lib file or by the mentioned preprocessor comment statements I linked previously.
JdH wrote:Maybe it is just me who thinks the current state of parser/common/executable-projects separation is a huge error prone mess.
The current state IS a huge error prone mess. But randomly chopping the source code up to make it compile somehow doesn't make things better.

[1] http://boost.2283326.n4.nabble.com/Spir ... 94042.html
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: CMake and the Windows FreeOrion SDK

#62 Post by Vezzra »

Geoff the Medio wrote:That said, it'll need to not break other OS builds, so attention for people besides me would be needed first.
I just tried the latest version of the patch on OSX. As expected it didn't work "out of the box", and even some quick attempts at fixes weren't successful (also no surprise, as I didn't really know what I've been doing). I don't think I'll get this patch building on OSX without some major effort, which I'm reluctant to invest if it's not going to be used (in the current form at least) anyway.

So, as far as OSX is concerned, I'm going to wait until you guys have decided how you want to proceed with that patch.

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

Re: CMake and the Windows FreeOrion SDK

#63 Post by JdH »

@Vezzra: Yes, OSX XCode-Project is broken, because of new files and files moved from one project to another and I don't know how to edit XCode Projects yet. But you are right, that there is no need in putting any efford into it yet.

@adrian_brother:
I can understand that we only want to export functionality that is needed, but currently, functionality is exported, not exported and included in the same header files. That's why it is hard for me to understand, what different parts of code are used for what part of our project.
With my patch, the windows binaries are a lot smaller and the linux binaries are about equal in size. Perhaps my patch does export more classes, but it also shares less classes at the same time, because some base classes are exported in my patch, but just included in current state. That's why I thought it would probably a good idea to clean it up a bit (no direct correlation with my current patch as I indeed only export everything in header files, that export something).
That said: I think you misunderstood my API approach suggestion: It wasn't about common/parser dependencies (I already have one solution to that in my patch and explained above), but about common&parser to executables.

And I really don't know, how you came to the opinion, I just want to mess around with the code a bit until something compiles again. I want to understand why the code is how it is (as for example explained with the parse project) and if we want to change something about it or not. I can happily think about and work on something else, if you all don't want to clean up the different projects.
I'd love to have a somewhat cleaner project structure. But I don't know if it is worth the effort, or if it just would be better for me to put a bit more time into just learn how it is now and then work with it.

I'm looking forward for your patch with the pragma directive to declare external symbols for the linker, as that would be the cleaner patch for getting the dll to work on windows without having to change much about the current code.
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

#64 Post by vincele »

Just a quick note about compile test on linux, with :
* llvm-3.6 as toolchain
* SVN up to date at r7722 + the 2 patches
* clean "Release" build

Code: Select all

Linking CXX executable ../freeoriond
CMakeFiles/freeoriond.dir/__/universe/UniverseGenerator.cpp.o: In function `__cxx_global_var_init46':
/home/vince/repo/upstream/FreeOrion-llvm/universe/UniverseGenerator.cpp:(.text.startup+0x249): undefined reference to `ValueRef::Constant<int>::Constant(int)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
server/CMakeFiles/freeoriond.dir/build.make:350: recipe for target 'freeoriond' failed
make[2]: *** [freeoriond] Error 1
CMakeFiles/Makefile2:471: recipe for target 'server/CMakeFiles/freeoriond.dir/all' failed
make[1]: *** [server/CMakeFiles/freeoriond.dir/all] Error 2
Makefile:137: recipe for target 'all' failed
make: *** [all] Error 2
No time now to investigate more.
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!

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

#65 Post by Dilvish »

vincele wrote:Just a quick note about compile test on linux, with :
* llvm-3.6 as toolchain
* SVN up to date at r7722 + the 2 patches
* clean "Release" build
Hmm, well then to be a bit more clear about my successful build and run attempt, it was also with a clean 'Release' build of SVN 7722 plus the two patches. I'm not very familiar with llvm but I think that's where our difference lies -- are you compiling with Clang? I'm compiling with gcc 4.8.1.

though if that's the only error you encounter then it may simply be an issue of an extra export being needed which gcc simply worked around for some reason in this case.
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

#66 Post by JdH »

I know this error. It's because of the template class instantiations are only compiled for vc (see end of ValueRef.cpp / gcc threw an error and worked without them).
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

#67 Post by vincele »

JdH wrote:I know this error. It's because of the template class instantiations are only compiled for vc (see end of ValueRef.cpp / gcc threw an error and worked without them).
OK, with this on top of your patches, it links properly with clang++-3.6. Replace line 1785 with:

Code: Select all

#if defined(_MSC_VER) || defined(__clang__)
Time for a quick runtime test...
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!

Post Reply