Page 4 of 4

Re: Compile Problem

Posted: Sun Feb 28, 2016 1:45 pm
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.

Re: Compile Problem

Posted: Sun Feb 28, 2016 2:14 pm
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.

Re: Compile Problem

Posted: Fri Oct 14, 2016 9:52 pm
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.

Re: Compile Problem

Posted: Sat Oct 15, 2016 12:56 am
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).

Re: Compile Problem

Posted: Fri Nov 11, 2016 12:18 pm
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!

Re: Compile Problem

Posted: Fri Nov 11, 2016 4:46 pm
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?

Re: Compile Problem

Posted: Sun Nov 13, 2016 3:16 pm
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

Re: Compile Problem

Posted: Sun Nov 13, 2016 3:54 pm
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.

Re: Compile Problem

Posted: Sun Nov 13, 2016 4:52 pm
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?

Re: Compile Problem

Posted: Sun Nov 13, 2016 5:03 pm
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?

Re: Compile Problem

Posted: Sun Nov 20, 2016 6:32 pm
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...

Re: Compile Problem

Posted: Tue Nov 22, 2016 11:17 am
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.

Re: Compile Problem

Posted: Tue Nov 22, 2016 12:30 pm
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.

Re: Compile Problem

Posted: Wed Nov 23, 2016 5:35 pm
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.

Re: Compile Problem

Posted: Tue Dec 20, 2016 6:10 pm
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.