Re: [Monotone-devel] conversion of a prcs repository & diff with keywords

[Chad Walstrom]

"Hugo Cornelis" <address@hidden>  wrote:
> Subversion does not support merge history, so wouldn't I loose the
> merge history in that case ?

Probably.

> I currently use keyword expansion in configure.in to synchronize the
> version identifier in the binary with the version identifier of the
> version control system.  No manual interaction necessary, so no
> mistakes possible.  This is what I have in my source file :
> 
> dnl $Format: "AM_INIT_AUTOMAKE(neurospacesread,$ProjectVersion$)" $
> 
> and the next line gets replaced with the macro call
> 
> AM_INIT_AUTOMAKE(neurospacesread,0.652)

This is not the preferred form of the macro.  Instead, you should be
calling: AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME])

e.g. AC_INIT([Neurospacesread], [0.652], address@hidden, [neurospacesread])

For substitution, you could use Nathaniel's suggestion:

e.g. AC_INIT([Neurospacesread], [$(cat _MTN/revision)] , address@hidden, 
[neurospacesread])

Then move your original AC_INIT call to AC_CONFIG_SRCDIR(src/foo.c)

e.g. AC_CONFIG_SRCDIR([src/neurospacesread.c])

And finally: `AM_INIT_AUTOMAKE([OPTIONS])'

e.g. AM_INIT_AUTOMAKE([gnu dist-bzip2 subdir-objects 1.9])

Take a look at the automake info manual for details.

> The version identifier propagates to config.h and to the sources and
> binaries.  The way I set things up, prcs enforces consistency
> between the repository identifiers and the identifiers in the
> releases that I build.  Can I do something alike with monotone ?

Yep.  Using the above AC_INIT line will automatically populate the
PACKAGE_STRING, PACKAGE_NAME, PACKAGE_VERSION, PACKAGE_BUGREPORT, and
PACKAGE_TARBALL defines in your config.h file or set them as -D
defines for the compiler (if you're not generating the config.h file).

The autoconf maintainers/developers suggest that people do not use
VERSION files or populate the version from shell commands for the
simple fact that a person who received your software from a tarball
may not have the same development environment that you do.  You cannot
rely upon _MTN/revision actually existing in their environment. 
Without _MTN/revision lying about, it'll fail.

In your Makefile.am, include something like this:
VERSION:
        if -f $(top_srcdir)/_MTN/revision; then \
                cp $(top_srcdir)/_MTN/revision $@ \
        else \
                echo "Unknown" > $@

Still, package release version and branch revisions are really
different beasts.  It makes sense to signify a release version by
changing the configure.in/configure.ac file manually and noting the
change in your ChangeLog.  If you want to make certain that the
revision is ALSO recorded (provided that the right environment
exists), then use this as an additional piece of information:

dnl In your aclocal.m4
dnl Populate the MTN_REVISION variable for autoconf substitution
define([MONOTONE_REVISION], [
AC_MSG_CHECKING([for monotone revision])
MTN_REVISION="Unknown"
if test -f _MTN/revision ; then
        MTN_REVISION=$(< _MTN/revision)
fi
AC_SUBST(MTN_REVISION)
AC_DEFINE(MTN_REVISION)
AC_MSG_RESULT([$MTN_REVISION])
]) 

Then call this in your configure.in/configure.ac file.  It'll allow
you to substitute templates from configure as well as use MTN_REVISION
as a define.

-- 
Chad Walstrom <address@hidden>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */