Experiences in the community

Just another WordPress.com weblog

Compilation and DVCS-2

This is going to be another long post, more about dvcs (probably git and a bit of subversion) and a bit about compiling tools as well.

Hi all,
First of all let me share somethings which I left out of the first post . Because the first post had become quite a bit longish than I had anticipated so left out how a nice/good make instance would leave a directory. I had shown a make error example but not of a successful make instance. Without further ado, here are the last 5 odd lines of a successful make instance/compilation completed.


mv -f .deps/tileset_editor.moc.Tpo .deps/tileset_editor.moc.Po
g++ -Wall -O3 -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/Qt3Support -DQT_CLEAN_NAMESPACE -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT3_SUPPORT -DQT_SHARED -Wall -O3 -o allacrost-editor editor_main.o editor.o dialog_boxes.o grid.o skill_editor.o sprites.o tileset.o tileset_editor.o effects.o fade.o image_base.o image.o interpolator.o particle_effect.o particle_manager.o particle_system.o shake.o text.o texture.o texture_controller.o video.o script.o script_read.o script_write.o script_modify.o utils.o class.o class_info.o class_registry.o class_rep.o create_class.o error.o exception_handler.o function.o inheritance.o link_compatibility.o object_rep.o open.o pcall.o scope.o stack_content_by_name.o weak_ref.o wrapper_base.o global.o global_actors.o global_effects.o global_objects.o global_skills.o global_utils.o defs_global.o mode_manager.o system.o dialog_boxes.moc.o editor.moc.o grid.moc.o skill_editor.moc.o tileset_editor.moc.o -L/usr/lib -lQtCore -lQtGui -lQtOpenGL -lQt3Support -lm -llua5.1 -lSDL_ttf -lvorbisfile -lopenal -lSDL -ljpeg -lpng -lGLU -lGL -lX11 -L/usr/X11R6/lib
make[2]: Leaving directory `/usr/local/src/allacrost-svntrunk/game'
make[1]: Leaving directory `/usr/local/src/allacrost-svntrunk/game'

The above output is from the make instance found in the game allacrost. The last few lines do nothing but creating the necessary *.o object files needed by the game. See for instance the first few *.o object files


editor_main.o editor.o dialog_boxes.o grid.o

I do not want to go into details of what object files are but a very brief explanation here should give an idea about it/them.

The last two lines are indications of a success in make where it says :-

make[2]: Leaving directory `/usr/local/src/allacrost-svntrunk/game'
make[1]: Leaving directory `/usr/local/src/allacrost-svntrunk/game'

If one wants to find more information about object files and its ilk they would do well to install the gcc-doc package in Debian. A single html file gives lot of goodies about gcc after installing the gcc-doc package ( see file:///usr/share/doc/gcc-4.4-doc/gcc.html in your favorite web-browser after installing the gcc-doc and its related gcc-version.doc package).

While we are on the subject of compilers, gcc itself is constantly going under development. For instance gcc-4.3 is just for stable, gcc-4.4, 4.5 and 4.6 are for everything but stable (read testing and unstable versions of debian) .

There is also a package called gcc-snapshot which probably experienced c++ developers might be using to see what new stuff is there ( it probably would be bit/quite buggy)

$ aptitude show gcc-snapshot
Package: gcc-snapshot
State: not installed
Version: 20110624-1
Priority: extra
Section: devel
Maintainer: Debian GCC Maintainers
Uncompressed Size: 366 M
Depends: binutils (>= 2.20.1-14~), libc6-dev-i386 (>= 2.5), libc6-dev (>=
2.13-5), libasound2 (> 1.0.18), libatk1.0-0 (>= 1.12.4), libc6 (>=
2.11), libcairo2 (>= 1.2.4), libcloog-ppl0 (>= 0.15.9-3~),
libfontconfig1 (>= 2.8.0), libfreetype6 (>= 2.2.1),
libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.24.0), libgmp10,
libgmpxx4ldbl, libgtk2.0-0 (>= 2.24.0), libice6 (>= 1:1.0.0),
libmpc2, libmpfr4, libpango1.0-0 (>= 1.14.0), libppl-c4, libppl9,
libsm6, libxrandr2 (>= 4.3), libxrender1, libxtst6, zlib1g (>=
1:1.1.4), libecj-java (>= 3.5.1), python
Suggests: binutils-gold (>= 2.20.1-14~)
Provides: c++-compiler, c++abi2-dev
Description: A SNAPSHOT of the GNU Compiler Collection
This package contains a recent development SNAPSHOT of all files contained
in the GNU Compiler Collection (GCC).

The source code for this package has been exported from SVN trunk.

DO NOT USE THIS SNAPSHOT FOR BUILDING DEBIAN PACKAGES!

This package will NEVER hit the testing distribution. It is used for
tracking gcc bugs submitted to the Debian BTS in recent development versions
of gcc.
Homepage: http://gcc.gnu.org/

Tags: devel::compiler, qa::old-rc-bugs

The above is not for me.

Anyways, do you remember me sharing about some projects where the first step is to make .configure file using a command called autoreconf . The project called allacrost uses the same procedure .

Allacrost uses subversion and after one has cloned the repository the fist thing one has to do is use the command :-

$autoreconf -i

This command basically looks for a file called configure-ac and makes a .configure script based on the code within the file. Below is the output when I run .autoreconf -i in that project directory.
/usr/local/src/allacrost-svntrunk/game$ autoreconf -i
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION
Makefile.am:322: `:='-style assignments are not portable
Makefile.am:325: `%'-style pattern rules are a GNU make extension

Sharing below the first couple of lines of the configure.ac macro:-

dnl -*- Autoconf -*-
dnl Process this file with autoconf to produce a configure script.

After this is done, the configure script is made. The first few lines of the configure script also confirms that gnu autoconf (or in our case the gnu autoreconf) was used to generate it.

#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.68 for Hero of Allacrost 0.1.0.

The rest should be familiar ground to all once the configure script is there.

Now while subversion is perhaps known to all, it has/had its share of issues. For large projects it is supposed to be not easily portable. It is not easy to work on something and throw away if it does not work, things like that.

The main idea/selling point of distributed version control systems is you could make and try out various things/ideas which a developer is not sure about. There are three main dvcs which are hyped/talked/known about and they are mercurial (known as hg and used by many big free software projects), the most famour perhaps though is Mozilla Firefox (and it was controversial when they were looking at other options for dvcs), git (famously known and used by Linus Trovals for the GNU/Linux kernel as well increasingly being used for Debian development) and bazaar (or bzr whose big feature is that its being used in ubuntu development).

Before going further, there is one tip that I use and can share when I am trying out these various games. As my memory is not that great, at times I become blank/do not know what dvcs/vcs/scm whatever is that project using. That moment I use ls . (press tab completion) . the moment I do that I would get either .svn or .git .hg or .bzr indicating what is there and what has to be done.

Anyways, let’s look at what mercurial does. The advantage of mercurial over subversion is its supposed to be more scalable, supports offline history (valuable to me), portable and does not require much of a different vocabulary than subversion does. One of the upsides is mercurial is pretty modular. By modular I mean is, mercurial itself is pretty simple and one can add lot of extensions (or not) depending on one’s need. It also helps it be not so much of a load on the CPU (not much of an issue on desktops but certainly perhaps something to look at if you are thinking of servers and alike.)

One of the games which uses mercurial for its development is a game called WarlockGauntlet. The only issue I have with this game is that the development, the tickets everything is done in Polish while the game itself is in English (or perhaps its il8n compatible). Either way its hard to follow the development as all the discussions are mostly in Polish.

Cloning/making duplicate from the repository is pretty simple . Its :-

$hg clone http://hg.assembla.com/gdpl wg

which is similar to checking out a subversion repository :-

$svn co https://allacrost.svn.sourceforge.net/svnroot/allacrost/trunk/game allacrost

As can be seen while the words are changed the logic is the same so people who are familiar to subversion.

The first thing to do whenever having an hg repo (either as a contributor or just a user) is to to make an hgrc file in .hg . This is mine :-


/usr/local/src/warlockgauntlet/.hg$ cat hgrc
[paths]
default = http://hg.assembla.com/gdpl
[ui]
username = shirishag75
verbose = True
[extensions]
color =
[color]
mode = ansi
diff.diffline = bold
diff.extended = cyan bold
diff.file_a = red bold
diff.file_b = green bold
diff.hunk = magenta
diff.deleted = red
diff.inserted = green
diff.changed = white
diff.trailingwhitespace = bold red_background
status.modified = magenta bold
status.added = green bold
status.removed = red bold
status.deleted = cyan bold
status.unknown = blue bold
status.ignored = black bold

Two extensions are enabled in my mercurial instance, the progress extension and the color extension. The progress extension gives a more info. about various things while color is about pretty output on the command-line.

Now warlock game compilation takes a slightly different/shorter path.They do not use/take services of a .configure script. It simply goes straight to make or in my case (as its a 64-bit distribution/environment) I have to use :-


make -f Makefile.x86_64

and after the compilation is done/finished, have to run the


./run

command/script which is a simple shell script.The script basically defines an additional directory from where the game binary will load the libraries from. By using it with export the user i.e. you and me ensure that the game binary will be able to use that/those shared libraries for the entire gnome-terminal session.

Now each time I have to update the repo I simply fire two commands :-


hg pull

This command simply pulls whatever changes have been done in the remote repository. An output of such a command is something like this :-


$ hg pull
real URL is http://hg.assembla.com//gdpl/
pulling from http://hg.assembla.com/gdpl
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)

As can be seen while it pulls the new version/changes to the file it asks us to run hg update to actually commit or make the changes in our local repository/working copy.

So then I run


$hg update -v

The -v is for verbose . This is useful to track which files got changed :-


$ hg update -v
resolving manifests
getting data/config.xml
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

One can see what changes have been done if you know the changesetid of each revision which can be looking at hg log -v . This is what the first two entries in my hg log -v look like :-

changeset: 301:0d90220d0bb0
tag: tip
user: dextero
date: Sat Jul 09 21:32:15 2011 +0200
files: data/config.xml
description:
re #1091 – updated config.xml’s version to make sure it overwrites old one

changeset: 300:f7a80996005a
user: dextero
date: Sat Jul 09 21:23:57 2011 +0200
files: data/config.xml data/locale/en/controls.xml
description:
test #1091 – renamed control schemes, erased Mousecast. “first game” screen now displays only Mouse(old: ‘most true’) and Keyboard(‘8-k’) schemes.

What is interesting to note here that the changesetid of each revision is unique. Apparently with each new revision an SHA1-key is generated (perhaps coupled with a mac address or whatever). By changesetid I mean :-


changeset: 301:0d90220d0bb0
changeset: 300:f7a80996005a

Anyways, while as an average joe I might not use it but developers and curious people would enjoy the hg diff which is similar to the command svn diff . Giving below an output of svn diff from the project dawn-rpg :-

/usr/local/src/dawn-rpg$ svn diff -r 889:890
Index: src/CEditor.h
===================================================================
— src/CEditor.h (revision 889)
+++ src/CEditor.h (revision 890)
@@ -35,29 +35,11 @@
class CEditor
{
public:
– CEditor() {
– enabled = false;
– tilepos_offset = 0;
– tilepos = 0;
– current_tilepos = 0;
– current_object = 0;
– objectedit_selected = -1;
– zoneToEdit = NULL;
– objectDescriptionFont = NULL;
– keybindingFont = NULL;
– tinyFont = NULL;
– adjacencyModeEnabled = false;
– for ( size_t curDirection=0; curDirection <= AdjacencyType::BOTTOM; ++curDirection ) {
– curDirectionAdjacencySelection[ curDirection ] = 0;
– }
– };
+ CEditor();
+ ~CEditor();

– ~CEditor() {
– }

void initFonts();

– bool KP_toggle_editor;
void DrawEditor();
void SaveZone();
void HandleKeys();
@@ -69,6 +51,8 @@
void setEnabled( bool enabled );
void loadNPCs();

+ bool KP_toggle_editor;
+
private:
void inc_tilepos();
void dec_tilepos();
Index: src/CEditor.cpp
===================================================================
— src/CEditor.cpp (revision 889)
+++ src/CEditor.cpp (revision 890)
@@ -31,6 +31,28 @@
extern CMessage message;
extern std::map allMobTypes;

+CEditor::CEditor()
+{
+ enabled = false;
+ tilepos_offset = 0;
+ tilepos = 0;
+ current_tilepos = 0;
+ current_object = 0;
+ objectedit_selected = -1;
+ zoneToEdit = NULL;
+ objectDescriptionFont = NULL;
+ keybindingFont = NULL;
+ tinyFont = NULL;
+ adjacencyModeEnabled = false;
+ for ( size_t curDirection=0; curDirection <= AdjacencyType::BOTTOM; ++curDirection ) {
+ curDirectionAdjacencySelection[ curDirection ] = 0;
+ }
+}
+
+CEditor::~CEditor()
+{
+}
+
namespace DawnInterface {
CNPC* addMobSpawnPoint( std::string mobID, int x_pos, int y_pos, int respawn_rate, int do_respawn );
}

Similarly, in hg diff you do the same/exact thing :-

/usr/local/src/warlockgauntlet$ hg diff -r 300:301
diff -r f7a80996005a -r 0d90220d0bb0 data/config.xml
--- a/data/config.xml Sat Jul 09 21:23:57 2011 +0200
+++ b/data/config.xml Sat Jul 09 21:32:15 2011 +0200
@@ -1,4 +1,4 @@
-
+

Now you see the power of hg vis-a-vis . While svn takes quite a while even to do a local repo diff ,hg is able to do the same in an almost instantaneous way. Even in this shallow sorta test I can appreciate why people choose/chose hg/mercurial over subversion as it quite a few benefits.

The last average joe command is :-

$hg parents
changeset: 301:0d90220d0bb0
tag: tip
user: dextero
date: Sat Jul 09 21:32:15 2011 +0200
files: data/config.xml
description:
re #1091 - updated config.xml's version to make sure it overrides old one

The hg parents command can be thought of as a sub-set of the svn info command. It basically gives the summary of the latest commit and the comment for the same.

One of the more interesting feature which I have not found in subversion or at least I do not know is the verify feature, hg is pretty good at it :-


$ hg verify
repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
warning: copy source of 'data/physicals/monsters/defs/baldurian.xml' not in parents of f1cc3beca032
5730 files, 302 changesets, 7202 total revisions
1 warnings encountered!

At my end at the moment it’s not such a great issue but is good to know that such a tool/feature exists. How it does that would require some looking into but still a nifty feature by all accounts.

The third and final instalment would attempt to cover git (the least conceptually clear to me and/all any miscellaneous notes)

That’s about it from me for now.

Single Post Navigation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: