Repository Cleanup and Fixes

For discussion of the code running behind the game

Moderator: Staff

User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Repository Cleanup and Fixes

Postby Roots » Thu Dec 06, 2012 5:53 am

Before we start bringing people back and making progress here again, there are some things that need to be done, and others that I'd like to be done.

1) Build is broken (on Linux)

I can't get the game to compile at all on Linux anymore (I did a clean checkout/build on Ubuntu 12.10). But Valyria Tear, which uses all the same libraries and same code, compiles fine. VT uses a Cmake build system though instead of our automake system. I've identfied two build problems on my system. The first is that the configure script fails to find the QT4 development library needed for the map editor. The second is that when the build tries to compile the Luabind code, it fails.

I'm not sure if the Windows or OSX builds suffer similar problems.

2) Upgrade Luabind version and move source

I believe we are still using an older version of Luabind. VT has already upgraded to using the latest version and we should as well. Also I want to move the Luabind source code from src/luabind to lib/luabind, or some other location. I'd greatly prefer that src/ contain only our own source and not any third party software, but I do recognize that it is much easier for us to compile Luabind ourselves than mess around with it being installed on a user's system.

3) Consider switching our Linux build system to Cmake

VT uses Cmake, and since that build system is already setup for us there, I think we should consider using it as well. automake has give us some headaches over the years and it can be difficult to maintain. If we do switch to cmake though, we'll need to do some minor changes from the VT Cmake system because I don't like how Cmake mucks up some of the directories (it puts the game binary in src/, for example).

4) Do a clean code formatting

Bertram ran some kind of tool on the entire Allacrost source code when he forked it to VT and it made a lot of changes to the source format which I dislike (because I'm very OCD about code formatting, for some reason). When we grab his code and put it back in Allacrost, I want to make sure that we are conforming to our own code standard. I did some research today and found a tool called astyle (http://astyle.sourceforge.net/) that should make this relatively easy to do. About the only change I intend to keep is removing tabs from our indentation syntax and replacing them with 4 spaces (I'll update the code standard to reflect this as well). I wrote the astyle configuration file below which I believe will format the code according to our standard.

Code: Select all

# Hero of Allacrost Astyle Options File
#
# This is a configuration file for the astyle (Artistic Style: http://astyle.sourceforge.net/) source
# formatter. Install astyle on your system and run it with this options file to format any C++ code to
# comply with the Allacrost code standard.
#
# The command below will apply the astyle configuration for the entire Allacrost C++ source tree.
# Usage: $ astyle --options="{path-to-file}allacrost_astyle.cfg" {path-to-sourcetree}/src

# To understand what all of these options do, refer to the astyle documentation
--indent=spaces=4
--style=java
--indent-switches
--indent-preprocessor
--max-instatement-indent=40
--pad-oper
--pad-header
--unpad-paren
--break-closing-brackets
--align-pointer=type
# CAUTION: no backup file is generated with the below option set because we can easily get the original file from the repository
--suffix=none
# Comment out the option below if you want to run astyle without a recursive directory search
--recursive
--lineend=linux


5) Import the VT code back into Allacrost

The final step will be to grab all of the code from VT and put it back into Allacrost. This may be a little bit tricky to do, particularly because VT uses a different set of maps and characters, and we want to make sure that we don't import any VT-specific material. I'd like to wait until VT has it's first release to finish this step so that we have a well-defined point where then projects were "in sync", but I also don't want VT's release schedule to hold us up either. If it's not released at the end of the month or sooner, we should probably just do the code import beforehand.


I'm going to be gradually working on all of these tasks over the next couple of weeks. Of course I'll appreciate any help, especially in regard to build systems as I'm not very good at that stuff. If there's any other critical changes that you think we need to make, let's discuss them here.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Repository Cleanup and Fixes

Postby Roots » Thu Dec 06, 2012 6:16 am

Oh, I knew I forgot something.

6) Updated Issue Tracker

We need to do something with our tracker (http://bugs.allacrost.org). The version we are running is way, way outdated. I'm hesitant to rely on the issue tracker provided by sourceforge, since we may be switching from SVN to git/mercurial sometime in the near future, or possibly moving away from SF to a new hosting provider altogether (unlikely, but I'm not counting out the possibility). Plus relying on Sourceforge hasn't worked out well for us in the past (for anything other than code and release management anyway), and I know that the last time I looked at their issue tracker (a couple years ago) it was pretty lame.

Not only that, but a lot of the issues in our current tracker have gone completely stale. It's hard to know what is still relevant and what isn't. So I'm considering if we should just throw out our bug database completely and start fresh. I'm not sure if we should stick to MantisBT (our current bug tracker) or consider possible alternatives. Mantis has been pretty nice to use, even though I don't think we've ever upgraded it. So it's first on my short list. If it has better repository integration that would be great, because I felt that was the one thing that it lacked.

Any thoughts on bug tracker changes/upgrades?
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Repository Cleanup and Fixes

Postby Roots » Fri Dec 07, 2012 11:10 am

Made some progress on these issues yesterday:

- Fixed the Linux compilation of the game. Still have problems with compiling the editor though.
- Upgraded Luabind version (but have not yet moved this source)
- Began importing some VT code back into Allacrost.


And here's where my state of mind is thus far on some of these issues:
- Let's stick with autotools and forget Cmake. We actually have a pretty nice build system setup with autotools (thanks largely to gorzuate), and I don't want to learn another build system and figure out release packaging. Plus moving to Cmake is apparently going to require us to make several changes to our source files as well.
- I investigated possibly bug tracker alternatives. I think that we should just go ahead and stick with MantisBT. I'm going to try to upgrade our version to the latest release soon.
- VT code import is going to be much more difficult and time-consuming than I thought. I don't think it's going to be as easy as copying the code over and then running the auto formatter
- On second though, I'd rather stick with tabs for indentation. It's worked for us just fine for years.


The reason why VT import is going to be difficult is that Bertram broke a large number of our code standard rules and made other unnecessary modifications to the code that will make this difficult. Particularly I've seen the following:

- All "using namespace std;" calls in source files were removed, and now std:: has to be added onto everything, everywhere.
- He's been removing the includes of defs.h in the code and instead inserted manual class declarations throughout header and source files
- All includes for header files were changed to include the path information. "#include map.h" became "#include src/modes/map/map.h", and so on

And the list goes on. Honestly I wish he had followed the "if it ain't broke, don't fix it" rule and not made all of these unnecessary formatting changes, but it is what it is. Unfortunately it's going to make it harder for our two projects to share code.


Anyway, for now I'm working on importing all of the engine code. I'll also be working on updating our MantisBT install.
Image
rujasu
Developer
Posts: 758
Joined: Sun Feb 25, 2007 5:40 am
Location: Maryland, USA

Re: Repository Cleanup and Fixes

Postby rujasu » Sat Dec 08, 2012 7:43 pm

- On second though, I'd rather stick with tabs for indentation. It's worked for us just fine for years.


Good. I hate the four-spaces formatting thing and it bothers me on all sorts of irrational levels that people actually like it. Ugh.
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Repository Cleanup and Fixes

Postby Roots » Sat Dec 08, 2012 7:49 pm

rujasu wrote:
- On second though, I'd rather stick with tabs for indentation. It's worked for us just fine for years.


Good. I hate the four-spaces formatting thing and it bothers me on all sorts of irrational levels that people actually like it. Ugh.


I'm glad you agree. :) I do understand the reasons why people would want space-only indentation (so that code looks consistent across editors). But it's so much easier to just insert/remove a tab than it is to tap the spacebar key four times. I know in most editors you can make tabs insert spaces instead, but when you are unindenting a block you still have to hit backspace four times instead of once. Plus it can be really easy to accidentally miss a space while indenting.

I am going to put a notice in the code standard though strongly recommending that people configure their editors to make tabs span 4 spaces. That way we all see the code the same way.
Image

Return to “Programming”

Who is online

Users browsing this forum: No registered users and 3 guests