There's no way to change what -version flag prints

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run any binary compiled with gflags with the -version argument
2. The output will just be the program name
3. There's no way to actually set a version

What is the expected output? What do you see instead?

The expectation is that gflags would support a way to add a build version that 
can be printed with the -version argument. Currently there's no way of doing 
this.

What version of the product are you using? On what operating system?

gflags 1.2. Ubuntu 10.10.

Please provide any additional information below.

The suggested way to support passing a version to gflags might be to support a 
DEFINE_VERSION macro that one can use to pass in the build version. The actual 
version might be passed to a .cc file while compiling using the g++ compiler's 
-D flag.

Original issue reported on code.google.com by mohit.a...@gmail.com on 26 Feb 2011 at 9:44

[GoogleCodeExporter]

The supported way of specifying a version now is to put it in 
SetUsageMessage().  Is that not sufficient for your needs?

Original comment by csilv...@gmail.com on 28 Feb 2011 at 9:37

• Changed state: WontFix

[GoogleCodeExporter]

SetUsageMessage() is certainly a workaround, but I was hoping for a 
SetVersion() method in future releases that is printed once one runs the 
executable with --version.

Original comment by aron.sus...@nutanix.com on 1 Mar 2011 at 6:34

[GoogleCodeExporter]

But SetUsageMessage()'s argument is already run when one uses --version.  What 
does SetVersion() add?

Original comment by csilv...@gmail.com on 1 Mar 2011 at 6:37

[GoogleCodeExporter]

Maybe I'm misreading the code, but it doesn't look like --version prints what 
SetUsageMessage() sets:

static void ShowVersion() {
  fprintf(stdout, "%s\n", ProgramInvocationShortName());
  // TODO: add other stuff, like a timestamp, who built it, what
  //       target they built, etc.

# if !defined(NDEBUG)
  fprintf(stdout, "Debug build (NDEBUG not #defined)\n");
# endif
}

On the other hand, SetUsageMessage() is:

void SetUsageMessage(const string& usage) {
  if (program_usage != NULL)
    ReportError(DIE, "ERROR: SetUsageMessage() called twice\n");
  program_usage = strdup(usage.c_str());      // small memory leak
}

Original comment by aron.sus...@nutanix.com on 1 Mar 2011 at 6:49

[GoogleCodeExporter]

Oh!  My mistake, I apologize.  SetUsageMessage() is shown for --help, but not 
for --version.  I'll reopen the bug, and think about the best way to handle 
versioning without widening the API.

Original comment by csilv...@gmail.com on 1 Mar 2011 at 8:10

• Changed state: New

[GoogleCodeExporter]

OK, I decided to just add a SetVersionString() command to gflags, to go along 
with SetUsageMessage().  It's not ideal to widen the API, but I agree it's 
useful to be able to have more information with --version.  This will be in the 
next release.

Original comment by csilv...@gmail.com on 3 Mar 2011 at 6:11

• Changed state: Started

[GoogleCodeExporter]

Thank you.

Original comment by aron.sus...@nutanix.com on 3 Mar 2011 at 6:15

[GoogleCodeExporter]

Just wondering when the next release of gflags is going to be out ?

Original comment by mohit.a...@gmail.com on 3 Jul 2011 at 10:54

[GoogleCodeExporter]

Good question.  The version-setting is really the only new functionality added 
since the last release (that I can see), so I haven't felt that much pressure 
to cut a new release.  Is it possible for you to use the svn-trunk rather than 
a released tarball, to do what you need to do?  If so, I'll go with my regular 
schedule, which would put a new gflags out in probably a month or two.  
Otherwise, I can try to push one sooner.

Original comment by csilv...@gmail.com on 6 Jul 2011 at 5:58

[GoogleCodeExporter]

No hurry - I was just asking because it's been a while since the last release.

Unrelated - I'm not sure whether you also manage glog. That seems to have 
several important issues pending for a long time that never seem to get 
addressed (e.g., dealing with forks etc). Is glog being actively developed ? 
Sorry for the digression, but I felt I might get a better response here than on 
the glog mailing list.

Original comment by aron.sus...@nutanix.com on 6 Jul 2011 at 6:04

[GoogleCodeExporter]

No, I don't manage glog, sorry.  I'm sorry to hear that folks there are being 
non-responsive!  I'll see if there's anything I can do.

Original comment by csilv...@gmail.com on 6 Jul 2011 at 6:42

[GoogleCodeExporter]

Hi, I'm the owner of glog. Sorry for being terribly quiet these days. I'll 
restart the work within a few months.

Original comment by shinichi...@gmail.com on 7 Jul 2011 at 9:19

[GoogleCodeExporter]

This is in gflags 1.6, just released.

Original comment by csilv...@gmail.com on 30 Jul 2011 at 2:47

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 30 Jul 2011 at 2:47

• Changed state: Fixed