Friday, March 12, 2010

Part 3a: xlog - Preparing to hack, the aftermath.

The previously published parts of this series can be found here:

Some build issues...

After completing a build, it would be nice if we could return the code the state we started from. This is actually more than a 'nice to have' as it is a useful indicator of completeness. For example, if a particular compiled file isn't removed in a 'make clean', then maybe the associated source code hasn't been added to the source repository. There is not necessarily any logic in this, except that something is wrong, needs to be looked at and fixed.

I think of this as being a zero'th order test for any software that I compile from source, and git makes this issue very easy to describe and characterise.

With regards to 'xlog', after a build and a 'make clean', the 'git status' command reveils the following (where I've reformatted the output just a little.) 

Changed but not updated:
  deleted:    po/xlog.pot
and
  modified:   CVS/Entries
  modified:   data/doc/CVS/Entries
  modified:   po/CVS/Entries
  modified:   src/CVS/Entries
and
Untracked files:
  AUTHORS
  CVSROOT/
  ChangeLog
  Makefile.in
  autom4te.cache/
  configure
  data/Makefile.in
  data/desktop/Makefile.in
  data/doc/Makefile.in
  data/dxcc/Makefile.in
  data/glabels/Makefile.in
  data/man/Makefile.in
  data/maps/3D2/Makefile.in
  data/maps/3Y/Makefile.in
  data/maps/E5/Makefile.in
  data/maps/FK/Makefile.in
  data/maps/FO/Makefile.in
  data/maps/FR/Makefile.in
  data/maps/HK0/Makefile.in
  data/maps/JD/Makefile.in
  data/maps/KH8/Makefile.in
  data/maps/Makefile.in
  data/maps/SV/Makefile.in
  data/maps/VP6/Makefile.in
  data/maps/VP8/Makefile.in
  data/mime/Makefile.in
  data/pixmaps/Makefile.in
  data/remote/Makefile.in
  data/utils/Makefile.in
  src/Makefile.in
  src/logfile/Makefile.in

The first issue is with po/xlog.pot, which has mysteriously disappeared. It can be restored with the following. 

$ git checkout -- po/xlog.pot
I have seen glib errors when trying to run the application and haven't got to the bottom of this yet. I don't see the error occur if I make sure that the above file is present, but I haven't been able to reliably replicate to problem.

The '''CVS/Entries''' files can be committed to the git repository, but looking at the actual differences shows that this is only due to timestamp changes from upstream. It would probably be safe enough to ignore these files, and git has a file that allows these this to be set. (An exercise for the reader. Have a look at the man page for git.) 

$ git diff CVS/Entries
diff --git a/CVS/Entries b/CVS/Entries
index 30be513..42e4863 100644
--- a/CVS/Entries
+++ b/CVS/Entries
@@ -36,4 +36,4 @@ D/xlog////
 /missing/1.3/Wed Jan 14 11:45:11 2009//
 /mkinstalldirs/1.3/Wed Jan 14 11:45:11 2009//
 /xlog-2.0.lsm/1.1/Tue Feb 10 09:33:11 2009//
-/aclocal.m4/1.8/Thu Mar 11 11:55:55 2010//
+/aclocal.m4/1.8/Thu Mar 11 12:54:52 2010//

Finally, other than '''AUTHORS''' and '''ChangeLog''' (which are symbolic links as specified in README.cvs) all of the other files have come into existence in the build process and should be able to be safely removed, as they didn't exist in the original source. 

$ rm -rf autom4te.cache
$ rm configure
$ find . -name Makefile.in | xargs -n 1 rm

This leaves use with the following, which is where we want to be: 

$ git status
# On branch master
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
# AUTHORS
# ChangeLog
nothing added to commit but untracked files present (use "git add" to track)

A git repository with the code that I will be working on in the next blog posts has been setup here: http://git.mawsonlakes.org/cgi-bin/gitweb.cgi?p=paul/xlog.

Posted by at No comments:
Labels: , ,

Monday, March 08, 2010

Appendix: References (links etc.) for xlog hacking.

Useful Webpages

xlog

git

git - The Fast Version Control System

epkg

epkg is an encap package manager.

Software Repository

I'll be updating my code changes to xlog here.
Posted by at No comments:
Labels: , ,

Part 3: xlog - Preparing to hack

The previously published parts of this series can be found here:
So, we've downloaded the source code for xlog from the CVS repoistory: 
  cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/xlog co xlog
Even before configuring, the first thing I do is put the whole thing into a Git repository. The main reason for doing this upfront is that it then becomes possible to see what files are created or altered during the software building process. When we get around to making changes we can then make use of branches and commits. 
  cd xlog
  git init-db
  git add .
  git commit -m 'Initial commit'
Use 'git status' to see which files are different.

Lets now build the software, as per README.cvs. 

  ln -s ...
  autoconf
  automake
  ./configure
  make
  make install
Now, 'make install' will fail unless you give yourself system (root) privileges as it will try to install the code into the system directories (eg. /usr/bin, /usr/lib etc.). For the developer, there are several methods to get around this requirement. I use a tool called 'epkg', which allows software to be installed

To update the repository from upstream: 

  (commit any outstanding changes to another branch)
  git checkout master
  cvs update
These changes can then be pulled into a local working branch by using: 
  git checkout (your-branch)
  git rebase master

Posted by at 1 comment:
Labels: , ,

Thursday, March 04, 2010

Part 2: Hacking on xlog

In the first part on "Hacking on xlog" I eluded to the fact that xlog was good, but that I wanted to made some changes to it. The following article discusses these changes. What changes do I want to make to xlog?
  • Be able to add additional rules for more contests - Currently xlog has some useful rules and checks (eg. duplicates) but they are either overly general (check for all the duplicates in a log file) or specific to a particular competition. It would be good able to support different contests rules by either an extension language or a plug-in or dynamic library architecture.
  • Make the User Interface (UI) layout configurable - It would be good to be able to modify the UI to suit the way that I setup and use my set radio. Gnome and Gtk+ applications can be written using libglade, where the UI is defined in an XML file along with the functions that they call. It is then possible to rearrange the interface via the XML code, without touching any of the underlying code. Currently, xlog has 'hardcoded' all of the widgets and their positions into the code of the application itself.
  • Add support for other forms of radio operation - Logging is necessary in on-air contests but there are other types of radio operation where a suitable logging application would also be very useful. Examples include: Running nets, Message Relaying and Emergency Operations.
  • Multiple Operator Support - Support for multi-user access and multiple user logs. This would be useful for multiple user stations and for collating logs for competition managers.
In order to make these changes and make any form of useful contribution, I'm going to have to download the code and spend some time poking around in it, just to understand how it works. More about this in my next post.
Posted by at No comments:
Labels: , ,
Subscribe to: Posts (Atom)