Help with setting up

[em3]

I'm trying to build freeorion, but I'm not really used to CMake. I only used VS solutions, make and SCons so far. As far as I can tell it's an endless cycle of firing it and then checking out what's missing, and then firing it again and checking out what's missing and entering the same path to SDK to another variable and then firing cmake again. Could it maybe accept a path to SDK and set everything up itself or is it too much to ask for?

I'm trying to prepare building environment on Windows with following caveats:

• I'm not going to have SDK and freeorion directory near each other. I have a separate folder to keep dependencies for my project and a separate folder to keep versioned sources. As such, bootstrap goes out of the window.
• I'm not using Visual Studio, but VS Code (or sometimes emacs) for building, so I'm plannign to take advantage of cmake --build and available CMake-focused extensions.
• I don't have git in my PATH, so I will need to modify the version getting target to allow configurable git executable path (through CMake, I guess?)
• I'd prefer to use ./build directory in freeorion sources to keep the compiled programs, but I guess it's not really standard? I mean, by default the VS solution seems to want to place everything in the repository's root folder. On linux and Mac OS it is recommended to build into ./build directory, but it's not even in .gitignore

Any tips or recommendations or kicks to the head for doing things non-kosher?

[o01eg]

There are some tries to enable cmake in Windows: https://github.com/freeorion/freeorion/pull/2388

[adrian_broher]

> I'm trying to build freeorion, but I'm not really used to CMake.
> Any tips or recommendations or kicks to the head for doing things non-kosher?

Don't bother. Upstream ignored every attempt to fix the Windows CMake build very hard in favour of the manual VS solutions, even when proposing soft migrations or preparations for this.

https://github.com/freeorion/freeorion/pull/1416
https://github.com/freeorion/freeorion/pull/2388

[em3]

That is unfortunate.

I was hoping to learn using CMake while contributing.

So, if I'm not using CMake and I absolutely do not want sources and SDK in the same directory, I will need to edit the solution files myself (or using python)?

[Geoff the Medio]

Upstream ignored every attempt to fix the Windows CMake build very hard in favour of the manual VS solutions, even when proposing soft migrations or preparations for this.

https://github.com/freeorion/freeorion/pull/1416
https://github.com/freeorion/freeorion/pull/2388

Ignored?

The first of those pull requests, made by you, is still marked work in progress. If it is / was done, or is ready for more testing, then please rebase and indicate this so I / we can do so, or just merge it yourself.

The second pull request was repeatedly tested and given feedback, until you wrote that it broke more than it fixed. If you now think it is worth merging, please write that or do so. I defer to your judgement for pull requests such as this.

I prefer to use the manually maintained VS solution files because I find the extra step of using CMake unnecessary and annoying, but I have no objection to making CMake work as well and will gladly merge or have you merge whatever changes to those scripts you think are good enough and that don't completely break the ability to use an MSVS solution file in parallel.

[adrian_broher]

Ignored?

The first of those pull requests, made by you, is still marked work in progress. If it is / was done, or is ready for more testing, then please rebase and indicate this so I / we can do so, or just merge it yourself.

Yes ignored. The feature already worked two years ago as intended and could already have been merged March 2017, except it broke the MSVS solutions. Now, after some thousand commits behind, its rotten and needs to be fixed.

The second pull request was repeatedly tested and given feedback, until you wrote that it broke more than it fixed. If you now think it is worth merging, please write that or do so. I defer to your judgement for pull requests such as this.

I still consider it the inferior solution as it doesn't allow the build of shared libraries and only somehow fixes the windows build by copying the behaviour of the VS solution. It doesn't fix the inherit flaws of it.

I prefer to use the manually maintained VS solution files because I find the extra step of using CMake unnecessary and annoying, but I have no objection to making CMake work as well and will gladly merge or have you merge whatever changes to those scripts you think are good enough and that don't completely break the ability to use an MSVS solution file in parallel.

Repeating again and again:

The VS Solution

• dictates the layout of the source code and the SDK structure, making changes an unnecessary PITA
• enforces the availability of python as a build dependency for no good reason
• duplicates the work required for build documentation
• doesn't provide any of the flexibility to allow multiple build trees or different build configurations
• forces the user to manually manage the SDK
• doesn't provide any build environment capability checking
• doesn't provide the capabilities to build release artifacts, which are a prequisite to do serious automated CI (fully automated weeklies/nightlies)

Counter argument so far:

• CMake is annoying

Seriously? The VS solution files are a hindrance for every advanced feature that could be provided by the build system and you are still in favour of that crutch.

Also:

[…] I / we can do so, or just merge it yourself.
[…] I defer to your judgement for pull requests such as this.

While I'm still a member of the freeorion group on GitHub, I don't have any more permissions on the repositories than a guest.

[em3]

dictates the layout of the source code and the SDK structure, making changes an unnecessary PITA

doesn't provide any of the flexibility to allow multiple build trees or different build configurations

Glad I'm not the only one bothered by this.

When I have time, I'll add ./build/ to .gitignore (as it's the suggested location for build on both Linux and MacOS) as a PR.

Adrian_broher, if you need someone, who doesn't really know CMake and didn't dig into .sln, .vcxproj, .props etc for some time, to do some grunt work with updating your PR, I'm up for it.

[adrian_broher]

Adrian_broher, if you need someone, who doesn't really know CMake and didn't dig into .sln, .vcxproj, .props etc for some time, to do some grunt work with updating your PR, I'm up for it.

Thanks for the suggestion, but I have a local branch, which is already up-to-date. However since the introduction of the Pending class I'm having a hard time implementing the shared library build on Windows.

[em3]

Any particular problems? Is this about move/copy constructors that you mentioned in GitHub?

[em3]

Anyway, know that I applaud you in your efforts. Know, that you are not doing this just for the benefit of your own pedantry.

[adrian_broher]

Any particular problems? Is this about move/copy constructors that you mentioned in GitHub?

I don't know as the CI results are way too old to interpret properly. You can give the rebased version a spin: [email protected]:adrianbroher/freeorion.git on the win-cmake branch.

[o01eg]

I made another try to enable Cmake for MS VS: https://github.com/freeorion/freeorion/pull/2435

[o01eg]

I've finished my PR to support non-XP and non-32 targets along with RelWithDebInfo configuration. I didn't touch packaging and installation and I don't enable tests itself because I get strange segfault in fo_system_test.exe which hard to solve without debug symbols:

Code: Select all

fo_systemtest_game.exe!boost::spirit::traits::inhibit_clear_queue<class boost::spirit::lex::lexertl::functor<struct boost::spirit::lex::lexertl::position_token<class std::_String_const_iterator<class std::_String_val<struct std::_Simple_types<char> > >,struct boost::mpl::vector<bool,int,double,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na,struct boost::mpl::na>,struct boost::mpl::bool_<1>,unsigned __int64>,class boost::spirit::lex::lexertl::detail::data,class std::_String_const_iterator<class std::_String_val<struct std::_Simple_types<char> > >,struct boost::mpl::bool_<1>,struct boost::mpl::bool_<1> > >(class boost::spirit::lex::lexertl::iterator<class boost::spirit
[email protected]@()
fo_systemtest_game.exe!parse::detail::parse_file<struct `anonymous namespace'::grammar,class GameRules>(struct parse::lexer const &,class boost::filesystem::path const &,class GameRules &)
fo_systemtest_game.exe!parse::game_rules(class boost::filesystem::path const &)

[em3]

Is SDK prepared for a debug or release build?

There are two paths to provide for (for example) vorbis file library, but SDK contains only a single libvorbisfile.lib (and pdb, but it could be from a debug build our a release with symbols build).

[o01eg]

Is SDK prepared for a debug or release build?

There are two paths to provide for (for example) vorbis file library, but SDK contains only a single libvorbisfile.lib (and pdb, but it could be from a debug build our a release with symbols build).

SDK builds as release with symbols.