The source archive is missing important imformation.

[Winter Knight]

I just downloaded the latest source code archive, and attempted to compile Spring. Unfortunately, there is no README or INSTALL file included, so I had to wing it. I noticed the SConstruct file, so I typed scons. I got the message "Run `scons configure' first.", so I did that next.

The output was several lines, and everything seemed to be good except for the last two lines. "Not all tests finished succesfully. You are probably missing one of the build dependencies. See config.log for details." config.log didn't have any helpful information.

You need a README file, and this file should include basic installation instructions, and the most imporatant part, build dependencies. Also, scons configure should report which build dependencies that it did not find.

I am sure this info is obvious to Spring developers, but to anybody else it is not. Regardless of whether this info is in the wiki (I couldn't find it in the wiki) it needs to be included with the source archive, and error messages should be more helpful.

[Auswaschbar]

Use cmake, it has better error messages. And also:
http://springrts.com/wiki/Building_Spring_on_Linux

[Winter Knight]

Thanks Auswaschbar, that link helped a lot.

I used cmake instead of scons, as Auswaschbar suggested, and it does have better error messages. It still wasn't acceptable, though. It told me something along the lines of, I needed to install boost. I already have boost. I just needed several subsets of boost that I didn't already have, and cmake didn't tell me which. Fortunately, The Building Spring on Linux page told me which subsets of boost I needed and more.

After installing the required libraries according to the wiki page, I ran cmake . and then make. 20 mins later, after the build was 66% complete, I got an error about boost::this_thread and boost::posix_time not being declared. The wiki page said that boost 1.35.* is required for the git repository. Apparently, it is required for the latest archive too (0.79.1.2). Because Spring is just a passing curiosity, and because updating boost would be a hassle, and potentially leave my build environment less stable, I have decided to give up on Spring for now. Perhaps when Spring becomes more stable, it won't require library versions that are so new (less than 1.5 years).

Here is a brief summary of my suggestions:

* README file for archives
* compile instructions for source archive
* better error messages when using scons configure and cmake
- when configure fails, it should specify which libraries need to be installed
- configure should fail when appropriate library versions are not installed
* Building_Spring_on_Linux needs to be updated to describe latest archive
* Building_Spring_on_Linux should have a bullet list of which libraries are required, and the minimum versions required

Including a README or INSTALL file with a link to http://springrts.com/wiki/Building_Spring_on_Linux would mostly fulfill 1 and 2 above.

[aegis]

if you're complaining about build hassle, you're probably using the wrong linux distro.

[Pressure Line]

tbfh, if you use any distro other than nice vanilla ubuntu (or windows XP lol) or another distro which has packages pre-built for it you lose the right to complain about the difficulty of building Spring (or anything really)

You want to forge your own path? Thats cool, just don't expect anyone to hold your hand. (although the linux setup guides could be more prominently linked in the wiki and on the forums (hint hint sticky in the linux forum))

[Winter Knight]

Lack of build instructions in the archive, and poor, unhelpful error messages during the configure stage are distro agnostic. Attacking my distro choice is poor behavior, and it doesn't even make sense in this context.

I have been very polite. I pointed out some things that are missing from the source archive, and made some recommendations on how to fix it. I even concluded with a bullet summary.

If you are going to defend the lackings in Spring, you can say that is Beta, pre-1.0 software.

[aegis]

because updating boost would be a hassle, and potentially leave my build environment less stable

that's not a problem with spring.

Lack of build instructions in the archive

the source archive was filed under the Source category, which was separate from and came *after* the Linux category, which had a link to the building spring on linux wiki page.

also, it's possible to use multiple versions of a library... you can specify library locations and header locations manually... the global build environment isn't incredibly fragile.

[hoijui]

I have been very polite.

I am the most intelligent in the spring community, and still no-one cares.. :/

but for real, what he sais is ultimately true. boost 1.34 is the standard in the long term support version of ubuntu (..you know what i mean, its 8.04 at the moment). it really is bad that we use a later version of boost then this, it should not be! it forced me to update my distro, and broke a lot of things in turn (graphics and other stuff). The same applies to the OpenAL version spring requires to work acceptable. Well its a bit different there, as you can still play with the version of ubuntu 8.04, if you disable sound completly (as it is too bad otherwise). Now, what i am saying is not, that we have to use the lib versions of ubuntu LTS, but if a dev wants to use a newer version, he should check with other devs or users if they have this version in their distro first!
This is particularly a problem with devs using distors like gentoo, where it is no problem to get latest versions of everything. but that is no excuse to break shit for eveyrone else, force users and devs to upgrade their distros and force package maintainers to release new boost versions for older distros. it is bad practise, and the inclusion of boost 1.35 perfeclty shows this! since it is requried for spring, we have had many many complaints and bug reports because of it, and up until now we have to supply fixes and workarounds.
I vote for a revert to boost 1.34.
whether it will be done or not, i will revert all commits from now on, that require me to fuck up my distro just to be able to compile/test spring.
The pure comfort/lazyness of a single dev is no valid argument against the huge ammount of problems it can cause for other devs and users.

edit: fix some typos

[Pressure Line]

Your choice of distro is fairly important (you never actually *said* what it was btw) since there are pre-compiled versions (of most popular programs) for the major distros (ubuntu, debian etc) although that is somewhat beside the point.

The point of the wiki is that *anyone* can edit it (you need an account though, but thats not exactly hard to set up) so for the love of whatever deity you hold dear, add the info and as aegis said, you would have had to scroll past the linux setup guide and distro specific compiles to get to the plain source tarballs


tbh, you are right in many respects, in as much as the documentation could be easier to access (although unless you go straight for "download source" or have an uncommon distro you have to go through the 'linux setup guide' which will either point you to more detailed instructions or a pre-compiled binary) and be kept more up-to-date.

but do remember this is all volunteer stuff, and with the 6 million linux distros out there there is no way anyone (well, not anyone who has all their marbles) is going to volunteer to write detailed instructions for compiling the source on every distro and keep them all up to date. (you'll even notice that even some of the more popular distros don't have up-to-date instructions)

*edit* hoijui raises some valid points!

[Auswaschbar]

To topic opener:

• I agree there should be some helpfile, I simply added one which refers to the wiki page, imho that should be enought
• the wiki is missing stuff? Thats bad, go add it please. Its a wiki, after all, and it would be a great help for others if you make it more usefull
• cmake errors: I took a look at the cmake findBoost-module, and what I read from it is, that it gives usefull error messages. It says when minimum version is not fulfilled, and also what libraries it is missing. Can you please post the COMPLETE buildlog somewhere (including the cmake-step). Maybe its a bug in cmake, or maybe your cmake-version is just to old.

Offtopic rant @ hoijui:
OpenAL on ubuntu LTS is not simply outdated, its just broken. It has lots of bugs and shortcommings. Requesting that audio in spring should not improve any further, neither use any "advanced" (I would call them basic, thought) features, just because you want to continue using a broken version, is just ridiculous.

Boost 1.34, on the other hand, is not broken, but very old. I wanted to check how old it was, but the release news is so old it isn't on their news-page any more. We had similar issues before (lol, I even think it was related to 1.35 and ubuntu a year back or so), someone added 1 or 2 ifdefs, everyone was happy and no need to rant.
You are to lazy to do this, and don't want to install a more recent version of your distribution? Fine, you could install boost from source. Or, if its to much work for you, you could use a backport package (https://launchpad.net/~pgquiles/+archive/ppa). But since you cannot use hardy for the rest of the century, you will have to update someday anyway.

but DON'T YELL AT ME FOR BREAKING YOUR DAMN COMPUTER.

[hoijui]

lets forget about OpenAL, i dont care much about that, as its "just" sound.

boost:
how old a version/release of something is, does not at all matter.
it was because of a few lines that used features of boost 1.35, that you added, why we could not use 1.34 anymore. if i remember right, you didnt even know they did not exist in 1.34 before i told you (cause you were using 1.37 or something, and i had 1.34, and compiling failed). I know now, thta it would have ben better to just compile boost myself instead of upgrading my distro, which does not really matter here.
thing is, we should have reverted these lines back then, and we would still use 1.34 now. all the problems all the many users had would hnot have occured. its simple:
(you happy, 50 others unhappy) vs (you unhappy, 50 others happy)
i may try a revert myself, if i am not too lazy.
and as said, i definatly will remvert such changes in the future.

[Auswaschbar]

Code: Select all

#if (BOOST_VERSION >= 103500)
// my stuff
#else
// insert your compatiblity stuff here
#endif

Is it that hard?

[Pxtl]

It constantly boggles the mind how much broken crap is languishing in Ubuntu LTS. I guess the idea is that everythign you have working in Ubuntu 8.04 will stay working... but everything broken stays broken.

[Auswaschbar]

boost:
how old a version/release of something is, does not at all matter.
it was because of a few lines that used features of boost 1.35, that you added, why we could not use 1.34 anymore. if i remember right, you didnt even know they did not exist in 1.34 before i told you (cause you were using 1.37 or something, and i had 1.34, and compiling failed). I know now, thta it would have ben better to just compile boost myself instead of upgrading my distro, which does not really matter here.
thing is, we should have reverted these lines back then, and we would still use 1.34 now. all the problems all the many users had would hnot have occured. its simple:
(you happy, 50 others unhappy) vs (you unhappy, 50 others happy)
i may try a revert myself, if i am not too lazy.
and as said, i definatly will remvert such changes in the future.

How it should have worked:

• I make a patch which used a "new" feature of boost
• you ifdef-ed it to make it compatible with your boost
• everyone would be happy

How it was done instead:

• I make a patch which used a "new" feature of boost
• you wanted me to fix it
• I didn't want to downgrade my boost version by 1 1/2 years
• nothing was done
• now we bitch around in the forums

[hoijui]

with russian accent:
"i agree my friend!"

the problem is that i have to find the parts that are broken.
my current ubuntu doesnt have 1.34 source packages anymore, i did not find the git commit(s) in gitk, and.. as said i was lazy
i remembered a recent post included the error message you get when compiling wiht boost 1.34, which was something with thread... but i did not find it emmediatly.

btw, this perfectly fits in:
http://www.youtube.com/watch?v=e-4aiJ9r_ro