321 lines
13 KiB
Markdown
321 lines
13 KiB
Markdown
[![Build Status](https://travis-ci.org/gflags/gflags.svg?branch=master)](https://travis-ci.org/gflags/gflags)
|
|
[![Build status](https://ci.appveyor.com/api/projects/status/4ctod566ysraus74/branch/master?svg=true)](https://ci.appveyor.com/project/schuhschuh/gflags/branch/master)
|
|
|
|
The documentation of the gflags library is available online at https://gflags.github.io/gflags/.
|
|
|
|
|
|
11 November 2018
|
|
----------------
|
|
|
|
I've just released gflags 2.2.2.
|
|
|
|
This maintenance release improves lives of Bazel users (no more "config.h" leaking into global include paths),
|
|
fixes build with recent MinGW versions, and silences a number of static code analyzer and compiler warnings.
|
|
The build targets exported by the CMake configuration of this library are now also prefixed by the package
|
|
name "gflags::" following a more recent (unwritten) CMake convention. The unprefixed target names are still
|
|
supported to avoid that dependent projects have to be modified due to this change in imported target names.
|
|
|
|
Please report any further issues with this release using the GitHub issue tracker.
|
|
|
|
|
|
11 July 2017
|
|
------------
|
|
|
|
I've just released gflags 2.2.1.
|
|
|
|
This maintenance release primarily fixes build issues on Windows and
|
|
false alarms reported by static code analyzers.
|
|
|
|
Please report any further issues with this release using the GitHub issue tracker.
|
|
|
|
|
|
25 November 2016
|
|
----------------
|
|
|
|
I've finally released gflags 2.2.0.
|
|
|
|
This release adds support for use of the gflags library as external dependency
|
|
not only in projects using CMake, but also [Bazel](https://bazel.build/),
|
|
or [pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/).
|
|
One new minor feature is added in this release: when a command flag argument
|
|
contains dashes, these are implicitly converted to underscores.
|
|
This is to allow those used to separate words of the flag name by dashes
|
|
to do so, while the flag variable names are required to use underscores.
|
|
|
|
Memory leaks reported by valgrind should be resolved by this release.
|
|
This release fixes build errors with MS Visual Studio 2015.
|
|
|
|
Please report any further issues with this release using the GitHub issue tracker.
|
|
|
|
|
|
24 March 2015
|
|
-------------
|
|
|
|
I've just released gflags 2.1.2.
|
|
|
|
This release completes the namespace change fixes. In particular,
|
|
it restores binary ABI compatibility with release version 2.0.
|
|
The deprecated "google" namespace is by default still kept as
|
|
primary namespace while symbols are imported into the new "gflags" namespace.
|
|
This can be overridden using the CMake variable GFLAGS_NAMESPACE.
|
|
|
|
Other fixes of the build configuration are related to the (patched)
|
|
CMake modules FindThreads.cmake and CheckTypeSize.cmake. These have
|
|
been removed and instead the C language is enabled again even though
|
|
gflags is written in C++ only.
|
|
|
|
This release also marks the complete move of the gflags project
|
|
from Google Code to GitHub. Email addresses of original issue
|
|
reporters got lost in the process. Given the age of most issue reports,
|
|
this should be negligable.
|
|
|
|
Please report any further issues using the GitHub issue tracker.
|
|
|
|
|
|
30 March 2014
|
|
-------------
|
|
|
|
I've just released gflags 2.1.1.
|
|
|
|
This release fixes a few bugs in the configuration of gflags\_declare.h
|
|
and adds a separate GFLAGS\_INCLUDE\_DIR CMake variable to the build configuration.
|
|
Setting GFLAGS\_NAMESPACE to "google" no longer changes also the include
|
|
path of the public header files. This allows the use of the library with
|
|
other Google projects such as glog which still use the deprecated "google"
|
|
namespace for the gflags library, but include it as "gflags/gflags.h".
|
|
|
|
20 March 2014
|
|
-------------
|
|
|
|
I've just released gflags 2.1.
|
|
|
|
The major changes are the use of CMake for the build configuration instead
|
|
of the autotools and packaging support through CPack. The default namespace
|
|
of all C++ symbols is now "gflags" instead of "google". This can be
|
|
configured via the GFLAGS\_NAMESPACE variable.
|
|
|
|
This release compiles with all major compilers without warnings and passed
|
|
the unit tests on Ubuntu 12.04, Windows 7 (Visual Studio 2008 and 2010,
|
|
Cygwin, MinGW), and Mac OS X (Xcode 5.1).
|
|
|
|
The SVN repository on Google Code is now frozen and replaced by a Git
|
|
repository such that it can be used as Git submodule by projects. The main
|
|
hosting of this project remains at Google Code. Thanks to the distributed
|
|
character of Git, I can push (and pull) changes from both GitHub and Google Code
|
|
in order to keep the two public repositories in sync.
|
|
When fixing an issue for a pull request through either of these hosting
|
|
platforms, please reference the issue number as
|
|
[described here](https://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control).
|
|
For the further development, I am following the
|
|
[Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)
|
|
with feature branch names prefixed by "feature/" and bugfix branch names
|
|
prefixed by "bugfix/", respectively.
|
|
|
|
Binary and source [packages](https://github.com/schuhschuh/gflags/releases) are available on GitHub.
|
|
|
|
|
|
14 January 2014
|
|
---------------
|
|
|
|
The migration of the build system to CMake is almost complete.
|
|
What remains to be done is rewriting the tests in Python such they can be
|
|
executed on non-Unix platforms and splitting them up into separate CTest tests.
|
|
Though merging these changes into the master branch yet remains to be done,
|
|
it is recommended to already start using the
|
|
[cmake-migration](https://github.com/schuhschuh/gflags/tree/cmake-migration) branch.
|
|
|
|
|
|
20 April 2013
|
|
-------------
|
|
|
|
More than a year has past since I (Andreas) took over the maintenance for
|
|
`gflags`. Only few minor changes have been made since then, much to my regret.
|
|
To get more involved and stimulate participation in the further
|
|
development of the library, I moved the project source code today to
|
|
[GitHub](https://github.com/schuhschuh/gflags).
|
|
I believe that the strengths of [Git](http://git-scm.com/) will allow for better community collaboration
|
|
as well as ease the integration of changes made by others. I encourage everyone
|
|
who would like to contribute to send me pull requests.
|
|
Git's lightweight feature branches will also provide the right tool for more
|
|
radical changes which should only be merged back into the master branch
|
|
after these are complete and implement the desired behavior.
|
|
|
|
The SVN repository remains accessible at Google Code and I will keep the
|
|
master branch of the Git repository hosted at GitHub and the trunk of the
|
|
Subversion repository synchronized. Initially, I was going to simply switch the
|
|
Google Code project to Git, but in this case the SVN repository would be
|
|
frozen and force everyone who would like the latest development changes to
|
|
use Git as well. Therefore I decided to host the public Git repository at GitHub
|
|
instead.
|
|
|
|
Please continue to report any issues with gflags on Google Code. The GitHub project will
|
|
only be used to host the Git repository.
|
|
|
|
One major change of the project structure I have in mind for the next weeks
|
|
is the migration from autotools to [CMake](http://www.cmake.org/).
|
|
Check out the (unstable!)
|
|
[cmake-migration](https://github.com/schuhschuh/gflags/tree/cmake-migration)
|
|
branch on GitHub for details.
|
|
|
|
|
|
25 January 2012
|
|
---------------
|
|
|
|
I've just released gflags 2.0.
|
|
|
|
The `google-gflags` project has been renamed to `gflags`. I
|
|
(csilvers) am stepping down as maintainer, to be replaced by Andreas
|
|
Schuh. Welcome to the team, Andreas! I've seen the energy you have
|
|
around gflags and the ideas you have for the project going forward,
|
|
and look forward to having you on the team.
|
|
|
|
I bumped the major version number up to 2 to reflect the new community
|
|
ownership of the project. All the [changes](ChangeLog.txt)
|
|
are related to the renaming. There are no functional changes from
|
|
gflags 1.7. In particular, I've kept the code in the namespace
|
|
`google`, though in a future version it should be renamed to `gflags`.
|
|
I've also kept the `/usr/local/include/google/` subdirectory as
|
|
synonym of `/usr/local/include/gflags/`, though the former name has
|
|
been obsolete for some time now.
|
|
|
|
|
|
18 January 2011
|
|
---------------
|
|
|
|
The `google-gflags` Google Code page has been renamed to
|
|
`gflags`, in preparation for the project being renamed to
|
|
`gflags`. In the coming weeks, I'll be stepping down as
|
|
maintainer for the gflags project, and as part of that Google is
|
|
relinquishing ownership of the project; it will now be entirely
|
|
community run. The name change reflects that shift.
|
|
|
|
|
|
20 December 2011
|
|
----------------
|
|
|
|
I've just released gflags 1.7. This is a minor release; the major
|
|
change is that `CommandLineFlagInfo` now exports the address in memory
|
|
where the flag is located. There has also been a bugfix involving
|
|
very long --help strings, and some other minor [changes](ChangeLog.txt).
|
|
|
|
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 [ChangeLog](ChangeLog.txt) 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
|
|
[ChangeLog](ChangeLog.txt) 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, [python-gflags](http://code.google.com/p/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 [ChangeLog](ChangeLog.txt) 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](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 [ChangeLog](ChangeLog.txt)
|
|
for more details.
|
|
|
|
If I don't hear any bad news for a few weeks, I'll release 1.0-final.
|