Re: revision control info in generated files

[Ralf Wildenhues]

* Jef Driesen wrote on Wed, Mar 31, 2010 at 02:49:48PM CEST:
> On 30/03/10 20:57, Ralf Wildenhues wrote:
> >There is a point to using FORCE over .PHONY: were you to mark
> >$(srcdir)/.git-version as phony, then the compilation of version.c would
> >always be emitted by 'make', even if the .git-version fils is up to
> >date.
> 
> Is FORCE some special built-in name (like .PHONY)? Or is just a
> random name for an "empty" target (e.g. one that depends on nothing
> and does nothing).

It's a random but common name for an empty target that should never be
up to date.  If you add a file named FORCE to the repository or your
build dir, or add a rule with commands to update FORCE to the makefile,
you're in trouble.  You can have these semantics also with a
double-colon rule without a prerequisite; double-colon rules are not
part of POSIX (SuSv3) make, but allowed as an extension (I don't know a
make that doesn't support them at all); for that, replace
  FORCE:
  $(srcdir)/.git-version: FORCE
        ...

with
  $(srcdir)/.git-version::
        ...

in the sample code.

> >Hope that helps.  I'm sure you can easily adapt this to the SCM of your
> >choice.
> 
> Sure. I use both git and subversion, and this are the commands I
> would use to retrieve the revision info:
> 
> git rev-parse --quiet --verify HEAD
> svnversion
> 
> The svnversion command is a little tricky because it does not fail
> when run outside a subversion tree.

'test -d $(top_srcdir)/.svn' should help with that.

> >FORCE:
> >$(srcdir)/.git-version: FORCE
> >     @if (test -d $(top_srcdir)/.git&&  cd $(srcdir) \
> >     &&  { git describe --dirty || git describe; } )>  .git-version-t 
> > 2>/dev/null \
> >     &&  ! diff .git-version-t $@>/dev/null 2>&1; then \
> >       mv -f .git-version-t $@; \
> >     else \
> >       rm -f .git-version-t; \
> >       if test -f $@; then :; else touch $@; fi; \
> >     fi
> >
> >EXTRA_DIST = $(srcdir)/.git-version
> >CLEANFILES = .git-version-t
> >
> >version.c: $(srcdir)/.git-version Makefile.am
> >     echo "const char foo_version[] = \""`cat $(srcdir)/.git-version`"\";">  
> > $@
> >
> >foo_SOURCES += version.c
> 
> I think I understand what's going on, except for a few little things:
> 
> Why the depencency on Makefile.am? I assume it has something to do
> with that FORCE target?

No.   I would like the files to be updated when I change the rule to
update the files.  This is arguable, something of a developer decision,
came probably from the moment I changed 'foo_version' to 'bar_version'
in the version.c rule and 'make' didn't rebuild, because the sources
were dirty before that already.

> Why do you add the .git-version-t file to CLEANFILES if it gets
> removed in the script?

So that an interrupted 'make' doesn't leave this file around.  'make'
removes at most the currently updated target when interrupted, but it
cannot know about other files (and with SIGQUIT or SIGKILL it can't even
remove $@, but that's not relevant here).

> And last but not least I'm using VPATH builds to build my code for
> multiple platforms from the same source directory.

Same here.

> Shouldn't the .git-version file be created inside the build directory,
> rather than the source directory?

No.  I want the .git-version file to be distributed, so that it is
present in an extracted tarball that has no .git information.  There,
the file will be in the source directory.  Might as well have it in the
source directory in my git checkout as well then, to be consistent;
otherwise, you may end up running into one of the 'make' portability
issues documented in info Autoconf 'Make Target Lookup'.

Cheers,
Ralf