I ran "Single player" and change Color, seed, number of AI and some another values.Vezzra wrote:Nicetom.i wrote:We did it
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...
Compile Problem
Moderator: Oberlus
Re: Compile Problem
Re: Compile Problem
Ah, ok, in that case you'll get a completely different map of course. Just wanted to make sure.tom.i wrote:I ran "Single player" and change Color, seed, number of AI and some another values.
Re: Compile Problem
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.Cpeosphoros wrote: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.Dilvish wrote:should do it; I didn't do anything fancy for my install of it.Code: Select all
sudo apt-get install libglew-dev
So, what I did (retroactively adding the missing apt-get install), and went very smooth, was:
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.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
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: Compile Problem
Updated the wiki (under Ubuntu where the libtiff4-dev was (now libtiff5-dev).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.
Re: Compile Problem
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!
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!
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: Compile Problem
What version of FreeOrion are you trying to build? What is the boost version you use?hhhmmmn wrote:Hello!
May be there is a solution for build error (I'm using arch linux, trying to build from AUR)
error:
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: Compile Problem
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
I have boost 1.62.0-3
Also version of gcc is 6.2.2-1
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: Compile Problem
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: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
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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: Compile Problem
Hm, I wonder if that's serious enough to warrant a bugfix release?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.
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: Compile Problem
I you feel like stemming the additional work.Vezzra wrote:Hm, I wonder if that's serious enough to warrant a bugfix release?
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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: Compile Problem
Unfortunately you've got a valid point here. I already have a hard time dealing with current issues, no room for extra work.adrian_broher wrote:I you feel like stemming the additional work.
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 don't want to open another can of worms right now, but what about monthly bugfix releases based on the current release?
I certainly can't do bugfix releases without this kind of support by the rest of the team.
Well, we can consider giving it a try... worst case, it doesn't work...Maybe starting with the next release, when the automatic builds are in place?
Re: Compile Problem
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 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.
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 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.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Compile Problem
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 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 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
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.
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
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.LGM-Doyle wrote:Geoff I agree with you about UI testing. I have never seen automated UI testing work.
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
[...] 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