git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Including git-describe info as version strings for generic "-v" output
@ 2012-01-21 19:09 Harry portobello
  2012-01-21 22:03 ` Junio C Hamano
  2012-01-23 11:16 ` demerphq
  0 siblings, 2 replies; 4+ messages in thread
From: Harry portobello @ 2012-01-21 19:09 UTC (permalink / raw)
  To: git; +Cc: Harry portobello

Hi all,

I hope the subject makes sense -- I'll explain what I'm trying to do.

I'm wondering what the best approaches are to being able to include
output from git-describe [1] for generic version strings in projects
managed by Git? This would have to work from within an
autotools-managed project.

At the moment, I've managed to hook the output from git-describe in to
a few .m4 files, which works only at ./configure time -- but of
course, with this being Git, I'd ideally like the same mechanism to
work in a situation where someone does:

$ git pull && make

It's knowing how to plumb this in to the Makefile.am part I'm hazy over.

Any help would be much appreciated.

Harry

[1] I know it's "git describe"; I'm using its hyphenated form for
clarity of context.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Including git-describe info as version strings for generic "-v" output
  2012-01-21 19:09 Including git-describe info as version strings for generic "-v" output Harry portobello
@ 2012-01-21 22:03 ` Junio C Hamano
  2012-01-22 16:03   ` Dirk Süsserott
  2012-01-23 11:16 ` demerphq
  1 sibling, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2012-01-21 22:03 UTC (permalink / raw)
  To: Harry portobello; +Cc: git

Harry portobello <harryportobello@gmail.com> writes:

> I hope the subject makes sense -- I'll explain what I'm trying to do.

Perhaps take a look at GIT-VERSION-GEN that is part of the Git source?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Including git-describe info as version strings for generic "-v" output
  2012-01-21 22:03 ` Junio C Hamano
@ 2012-01-22 16:03   ` Dirk Süsserott
  0 siblings, 0 replies; 4+ messages in thread
From: Dirk Süsserott @ 2012-01-22 16:03 UTC (permalink / raw)
  To: Harry portobello; +Cc: Junio C Hamano, git

Am 21.01.2012 23:03 schrieb Junio C Hamano:
> Harry portobello <harryportobello@gmail.com> writes:
> 
>> I hope the subject makes sense -- I'll explain what I'm trying to do.
> 
> Perhaps take a look at GIT-VERSION-GEN that is part of the Git source?


At work, we have the same "problem". I solved it like so:

version.h:
----------------------------------------------
#ifndef __version_h__
#define __version_h__

#ifdef __cplusplus
extern "C" {
#endif

/*
 * Returns a version string as defined with the -D compiler switch.
 */
char const * software_version();

#ifdef __cplusplus
}
#endif

#endif
----------------------------------------------


version.c:
----------------------------------------------
#include "version.h"

char const * software_version()
{
    return SW_VERSION;
}
----------------------------------------------

And then make sure that ONLY version.c gets compiled like this:

gcc -DSW_VERSION=\"$(git describe --dirty)\" \
    [other options] \
    -c version.c -o version.o

Actually I use Scons to build my software (not Make). Scons
automatically keeps track of dependencies and changed compiler switches
between its runs. Thus it will re-compile version.c if the output of
git-describe changes. That's why Scons users must make sure that the
-D-switch is given only to version.c (else Scons would re-compile ALL
files because of the different argument to -D).

If you are using Make then make sure that version.c gets compiled
always. The drawback is that your app will be re-linked with every
single Make run.

That's why I prefer Scons: it calculates the dependencies on a checksum
basis. If the *contents* of version.c together with the compiler options
didn't change, it won't re-compile it. Furtermore: if the *contents* of
version.o didn't change, it won't re-link. Timestamps don't matter to
Scons. But that's another topic :-)

HTH
    Dirk

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Including git-describe info as version strings for generic "-v" output
  2012-01-21 19:09 Including git-describe info as version strings for generic "-v" output Harry portobello
  2012-01-21 22:03 ` Junio C Hamano
@ 2012-01-23 11:16 ` demerphq
  1 sibling, 0 replies; 4+ messages in thread
From: demerphq @ 2012-01-23 11:16 UTC (permalink / raw)
  To: Harry portobello; +Cc: git

On 21 January 2012 20:09, Harry portobello <harryportobello@gmail.com> wrote:
> Hi all,
>
> I hope the subject makes sense -- I'll explain what I'm trying to do.
>
> I'm wondering what the best approaches are to being able to include
> output from git-describe [1] for generic version strings in projects
> managed by Git? This would have to work from within an
> autotools-managed project.
>
> At the moment, I've managed to hook the output from git-describe in to
> a few .m4 files, which works only at ./configure time -- but of
> course, with this being Git, I'd ideally like the same mechanism to
> work in a situation where someone does:
>
> $ git pull && make
>
> It's knowing how to plumb this in to the Makefile.am part I'm hazy over.
>
> Any help would be much appreciated.

FWIW Perl does something like this. Have a look at the Perl makefiles
for an example.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-01-23 11:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-21 19:09 Including git-describe info as version strings for generic "-v" output Harry portobello
2012-01-21 22:03 ` Junio C Hamano
2012-01-22 16:03   ` Dirk Süsserott
2012-01-23 11:16 ` demerphq

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).