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.

No comments: