mirror of
https://github.com/gflags/gflags.git
synced 2025-04-11 15:52:55 +00:00
* google-gflags: version 1.6 * BUGFIX: Fix a bug where we were leaving out a required $(top_srcdir) * Fix definition of clstring (jyrki) * Split up flag declares into its own file (jyrki) * Add --version support (csilvers) * Update teh README for gflags with static libs * Update acx_pthread.m4 for nostdlib * Change REparseCommandLineFlags to return void (csilvers) * Some doc typofixes and example augmentation (various) R=jperkins DELTA=44 (41 added, 0 deleted, 3 changed) Revision created by MOE tool push_codebase. MOE_MIGRATION=2838 git-svn-id: https://gflags.googlecode.com/svn/trunk@56 6586e3c6-dcc4-952a-343f-ff74eb82781d
119 lines
5 KiB
Text
119 lines
5 KiB
Text
== 29 July 2011 ==
|
|
|
|
I've just released gflags 1.6. The major new feature in this release
|
|
is support for setting version info, so that --version does something
|
|
useful.
|
|
|
|
One minor change has required bumping the library number:
|
|
`ReparseCommandlineFlags` now returns `void` instead of `int` (the int
|
|
return value was always meaningless). Though I doubt anyone ever used
|
|
this (meaningless) return value, technically it's a change to the ABI
|
|
that requires a version bump. A bit sad.
|
|
|
|
There's also a procedural change with this release: I've changed the
|
|
internal tools used to integrate Google-supplied patches for gflags
|
|
into the opensource release. These new tools should result in more
|
|
frequent updates with better change descriptions. They will also
|
|
result in future `ChangeLog` entries being much more verbose (for better
|
|
or for worse).
|
|
|
|
See the
|
|
[http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.6/ChangeLog ChangeLog]
|
|
for a full list of changes for this release.
|
|
|
|
=== 24 January 2011 ===
|
|
|
|
I've just released gflags 1.5. This release has only minor changes
|
|
from 1.4, including some slightly better reporting in --help, and
|
|
an new memory-cleanup function that can help when running gflags-using
|
|
libraries under valgrind. The major change is to fix up the macros
|
|
(`DEFINE_bool` and the like) to work more reliably inside namespaces.
|
|
|
|
If you have not had a problem with these macros, and don't need any of
|
|
the other changes described, there is no need to upgrade. See the
|
|
[http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.5/ChangeLog ChangeLog]
|
|
for a full list of changes for this release.
|
|
|
|
=== 11 October 2010 ===
|
|
|
|
I've just released gflags 1.4. This release has only minor changes
|
|
from 1.3, including some documentation tweaks and some work to make
|
|
the library smaller. If 1.3 is working well for you, there's no
|
|
particular reason to upgrade.
|
|
|
|
=== 4 January 2010 ===
|
|
|
|
I've just released gflags 1.3. gflags now compiles under MSVC, and
|
|
all tests pass. I *really* never thought non-unix-y Windows folks
|
|
would want gflags, but at least some of them do.
|
|
|
|
The major news, though, is that I've separated out the python package
|
|
into its own library, [http://code.google.com/p/python-gflags python-gflags].
|
|
If you're interested in the Python version of gflags, that's the place to
|
|
get it now.
|
|
|
|
=== 10 September 2009 ==
|
|
|
|
I've just released gflags 1.2. The major change from gflags 1.1 is it
|
|
now compiles under MinGW (as well as cygwin), and all tests pass. I
|
|
never thought Windows folks would want unix-style command-line flags,
|
|
since they're so different from the Windows style, but I guess I was
|
|
wrong!
|
|
|
|
The other changes are minor, such as support for --htmlxml in the
|
|
python version of gflags.
|
|
|
|
=== 15 April 2009 ===
|
|
|
|
I've just released gflags 1.1. It has only minor changes fdrom gflags
|
|
1.0 (see the
|
|
[http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.1/ChangeLog ChangeLog]
|
|
for details). The major change is that I moved to a new
|
|
system for creating .deb and .rpm files. This allows me to create
|
|
x86_64 deb and rpm files.
|
|
|
|
In the process of moving to this new system, I noticed an
|
|
inconsistency: the tar.gz and .rpm files created libraries named
|
|
libgflags.so, but the deb file created libgoogle-gflags.so. I have
|
|
fixed the deb file to create libraries like the others. I'm no expert
|
|
in debian packaging, but I believe this has caused the package name to
|
|
change as well. Please let me know (at
|
|
[mailto:google-gflags@googlegroups.com
|
|
google-gflags@googlegroups.com]) if this causes problems for you --
|
|
especially if you know of a fix! I would be happy to change the deb
|
|
packages to add symlinks from the old library name to the new
|
|
(libgoogle-gflags.so -> libgflags.so), but that is beyond my knowledge
|
|
of how to make .debs.
|
|
|
|
If you've tried to install a .rpm or .deb and it doesn't work for you,
|
|
let me know. I'm excited to finally have 64-bit package files, but
|
|
there may still be some wrinkles in the new system to iron out.
|
|
|
|
===1 October 2008===
|
|
|
|
gflags 1.0rc2 was out for a few weeks without any issues, so gflags
|
|
1.0 is now released. This is much like gflags 0.9. The major change
|
|
is that the .h files have been moved from `/usr/include/google` to
|
|
`/usr/include/gflags`. While I have backwards-compatibility
|
|
forwarding headeds in place, please rewrite existing code to say
|
|
{{{
|
|
#include <gflags/gflags.h>
|
|
}}}
|
|
instead of
|
|
{{{
|
|
#include <google/gflags.h>
|
|
}}}
|
|
|
|
I've kept the default namespace to google. You can still change with
|
|
with the appropriate flag to the configure script (`./configure
|
|
--help` to see the flags). If you have feedback as to whether the
|
|
default namespace should change to gflags, which would be a
|
|
non-backwards-compatible change, send mail to
|
|
`google-gflags@googlegroups.com`!
|
|
|
|
Version 1.0 also has some neat new features, like support for bash
|
|
commandline-completion of help flags. See the
|
|
[http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.0rc2/ChangeLog
|
|
ChangeLog] for more details.
|
|
|
|
If I don't hear any bad news for a few weeks, I'll release 1.0-final.
|