Compile Problem

Questions, problems and discussion about compiling FreeOrion.

Moderator: Oberlus

Message
Author
tom.i
Space Krill
Posts: 5
Joined: Sun Feb 28, 2016 7:36 am

Re: Compile Problem

#46 Post by tom.i »

Vezzra wrote:
tom.i wrote:We did it ;)
Nice :D

One question however: that screenshot above, is that from a default quickstart game, or did you run a single player game and change any of the default game settings? Because what I see is not what you get when you just launch a default quickstart game right after a fresh install...
I ran "Single player" and change Color, seed, number of AI and some another values.

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

Re: Compile Problem

#47 Post by Vezzra »

tom.i wrote:I ran "Single player" and change Color, seed, number of AI and some another values.
Ah, ok, in that case you'll get a completely different map of course. Just wanted to make sure.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: Compile Problem

#48 Post by MatGB »

Cpeosphoros wrote:
Dilvish wrote:

Code: Select all

sudo apt-get install libglew-dev
should do it; I didn't do anything fancy for my install of it.
Necroing this. That line of code should be in the Wiki page, together with the other "apt-get install" statements. I was trying to compile on a Linux Mint box and had a hard time with a "Couldn't find GLEW" message.

So, what I did (retroactively adding the missing apt-get install), and went very smooth, was:

Code: Select all

sudo apt-get install build-essential git pkg-config libltdl-dev cmake libboost-all-dev
sudo apt-get install python2.7-dev libfreetype6-dev libsdl2-dev libvorbis-dev libtiff4-dev libopenal-dev
sudo apt-get install libglew-dev

cd git
git clone git://github.com/freeorion/freeorion
cd freorion
mkdir freeorion.build
cd freeorion.build
ln -s ../freeorion/default .
cmake ../freeorion
make -j9
./freeorion
I had to "mine" that sequence of commands from various places in the wiki and this forum. I think it should be all together in an easily accessible place in the wiki.
IT basically is now, thanks to whoever did this. Due to a Linux reinstall, I've had to go trhough this again, and libtiff4-dev is now libtiff5-dev, so we need to update the wiki for that, game finally runs fine, now I need to copy across my persistent config, the game is really weird on default settings, everything's in the wrong place.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

AndrewW
Juggernaut
Posts: 791
Joined: Mon Feb 04, 2013 10:15 pm

Re: Compile Problem

#49 Post by AndrewW »

MatGB wrote:IT basically is now, thanks to whoever did this. Due to a Linux reinstall, I've had to go trhough this again, and libtiff4-dev is now libtiff5-dev, so we need to update the wiki for that, game finally runs fine, now I need to copy across my persistent config, the game is really weird on default settings, everything's in the wrong place.
Updated the wiki (under Ubuntu where the libtiff4-dev was (now libtiff5-dev).

hhhmmmn
Space Krill
Posts: 2
Joined: Fri Nov 11, 2016 12:14 pm

Re: Compile Problem

#50 Post by hhhmmmn »

Hello!
May be there is a solution for build error (I'm using arch linux, trying to build from AUR)
error:
/usr/include/boost/spirit/home/qi/detail/alternative_function.hpp:30:46: error: no type named ‘types’ in ‘boost::spirit::qi::detail::find_substitute<boost::optional<boost::variant<std::vector<Effect::EffectBase*>, Effect::EffectBase*> >, std::vector<Effect::EffectBase*> >::variant_type {aka class boost::optional<boost::variant<std::vector<Effect::EffectBase*>, Effect::EffectBase*> >}’

Thank you for attention!

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

Re: Compile Problem

#51 Post by adrian_broher »

hhhmmmn wrote:Hello!
May be there is a solution for build error (I'm using arch linux, trying to build from AUR)
error:
What version of FreeOrion are you trying to build? What is the boost version you use?
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

hhhmmmn
Space Krill
Posts: 2
Joined: Fri Nov 11, 2016 12:14 pm

Re: Compile Problem

#52 Post by hhhmmmn »

I'm trying to build current version from AUR: freeorion 0.4.6-1
I have boost 1.62.0-3

Also version of gcc is 6.2.2-1

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

Re: Compile Problem

#53 Post by adrian_broher »

hhhmmmn wrote:I'm trying to build current version from AUR: freeorion 0.4.6-1
I have boost 1.62.0-3

Also version of gcc is 6.2.2-1
Starting with Boost 1.61 there is a bug in boost, which breaks boost::spirit. We had a workaround in place with the freeorion 0.4.6 release, which fixes this for boost 1.61 but no later versions. This workaround was extended later in the latest development version to any future boost version. To build the 0.4.6 release you need to apply this patch:

https://github.com/freeorion/freeorion/ ... d1396d46d8 (github page)
https://github.com/freeorion/freeorion/ ... 46d8.patch (link to raw patch)

The Arch package maintainer should update the package/build script accordingly to apply this patch before building.
Last edited by adrian_broher on Sun Nov 13, 2016 4:59 pm, edited 1 time in total.
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: Compile Problem

#54 Post by Vezzra »

adrian_broher wrote:We had a workaround in place with the freeorio 0.4.6 release, which fixes this for boost 1.61 but no later versions.
Hm, I wonder if that's serious enough to warrant a bugfix release?

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

Re: Compile Problem

#55 Post by adrian_broher »

Vezzra wrote:Hm, I wonder if that's serious enough to warrant a bugfix release?
I you feel like stemming the additional work.


I don't want to open another can of worms right now, but what about monthly bugfix releases based on the current release? Maybe starting with the next release, when the automatic builds are in place?
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: Compile Problem

#56 Post by Vezzra »

adrian_broher wrote:I you feel like stemming the additional work.
Unfortunately you've got a valid point here. I already have a hard time dealing with current issues, no room for extra work. :(
I don't want to open another can of worms right now, but what about monthly bugfix releases based on the current release?
In theory that's an idea worth considering, in practice see above. That would mean a substantial amount of additional work, not only on my part. It would require all contributors to practice discipline when providing bugfixes, everyone would need to pay attention if a fix they provide fixes a bug/issue introduced after the last release or has already been around before the last release (and just hasn't been discovered yet, or not considered release-stopping). In the latter case it should be determined if the fix can be applied to the release branch of the last release, and if yes, cherry-picked into that release branch. Ideally of course by the one providing the fix, as that's the person best fitted to solve potential conflicts, otherwise at least tag the PR with the fix as "status:cherry-pick for release", so someone else can take care of that.

I certainly can't do bugfix releases without this kind of support by the rest of the team.
Maybe starting with the next release, when the automatic builds are in place?
Well, we can consider giving it a try... worst case, it doesn't work...

LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Re: Compile Problem

#57 Post by LGM-Doyle »

Most projects that do rolling releases have automatic builds and automatically run test suites, with some reasonable level of coverage.

Our testing is done at a low level by the devs, and then high level and UI testing is done by humans. Testing a release to determine that a change has not broken a feature that the original dev does not/did not use while testing takes time.

However, now that we have automatic builds :D which assures that the build works on all platforms, we could aspire to a test suite as a way to speed up our current release cycle/procedure until it is a continuous release style.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Compile Problem

#58 Post by Geoff the Medio »

LGM-Doyle wrote:Our testing is done at a low level by the devs, and then high level and UI testing is done by humans. Testing a release to determine that a change has not broken a feature that the original dev does not/did not use while testing takes time.

However, now that we have automatic builds :D which assures that the build works on all platforms, we could aspire to a test suite as a way to speed up our current release cycle/procedure until it is a continuous release style.
People have been suggesting this for years, but I still don't see how it will be possible to do thorough automatic tests for UI issues and balance considerations, which are a substantial portion of the testing effort... Things with clear pass/fail conditions are reasonable to automate, like "does it compile?" or "does the effectsgroup do what it's supposed to", though even in the latter case, setting up a thorough set of tests, and then maintaining them, will be a huge amount of ongoing work. That said, some people seem to quite like doing that sort of work, and I'd welcome the capability. adrian_broher managed to get the SDK to build and assemble automatically, which I didn't expect would work.

LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Re: Compile Problem

#59 Post by LGM-Doyle »

Geoff I agree with you about UI testing. I have never seen automated UI testing work.

I also agree that reaching 100% coverage and maintaining it, is a wasted effort.

However, there is great gulf between our current level of automated test setup and complete UI testing. We might be missing out on the benefits of 5% coverage.

User avatar
em3
Vacuum Dragon
Posts: 630
Joined: Sun Sep 25, 2011 2:51 pm

Re: Compile Problem

#60 Post by em3 »

LGM-Doyle wrote:Geoff I agree with you about UI testing. I have never seen automated UI testing work.
Well, there's https://www.froglogic.com/squish/, but it's not free, and I guess it requires you to use one of the "major GUI technologies" - I use Qt at work, so that's not a problem.

The point is - automated UI testing is a thing.
https://github.com/mmoderau
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556

Post Reply