Name Date Size

..27-Apr.-20224 KiB

.gitattributesH A D11-Oct.-2021113

.gitignoreH A D11-Oct.-2021407

.travis.ymlH A D11-Oct.-2021409

appveyor.ymlH A D11-Oct.-20211.4 KiB

AUTHORS.txtH A D11-Oct.-202132

bazel/H08-Jan.-20224 KiB

BUILDH A D08-Jan.-2022629

ChangeLog.txtH A D11-Oct.-202112.7 KiB

cmake/H11-Oct.-20214 KiB

CMakeLists.txtH A D27-Jul.-202229 KiB

COPYING.txtH A D11-Oct.-20211.4 KiB

doc/H27-Jul.-20224 KiB

INSTALL.mdH A D11-Oct.-20214.5 KiB

README.mdH A D11-Oct.-202113.3 KiB

src/H11-Oct.-20214 KiB

test/H11-Oct.-20214 KiB

WORKSPACEH A D11-Oct.-2021255

README.md

1[![Build Status](https://travis-ci.org/gflags/gflags.svg?branch=master)](https://travis-ci.org/gflags/gflags)
2[![Build status](https://ci.appveyor.com/api/projects/status/4ctod566ysraus74/branch/master?svg=true)](https://ci.appveyor.com/project/schuhschuh/gflags/branch/master)
3
4The documentation of the gflags library is available online at https://gflags.github.io/gflags/.
5
6
711 November 2018
8----------------
9
10I've just released gflags 2.2.2.
11
12This maintenance release improves life of Bazel users (no more "config.h" leaking into global include paths),
13fixes build with recent MinGW versions, and silences a number of static code analyzer and compiler warnings.
14The build targets exported by the CMake configuration of this library are now also prefixed by the package
15name "gflags::" following a more recent (unwritten) CMake convention. The unprefixed target names are still
16supported to avoid that dependent projects have to be modified due to this change in imported target names.
17
18Please report any further issues with this release using the GitHub issue tracker.
19
20
2111 July 2017
22------------
23
24I've just released gflags 2.2.1.
25
26This maintenance release primarily fixes build issues on Windows and
27false alarms reported by static code analyzers.
28
29Please report any further issues with this release using the GitHub issue tracker.
30
31
3225 November 2016
33----------------
34
35I've finally released gflags 2.2.0.
36
37This release adds support for use of the gflags library as external dependency
38not only in projects using CMake, but also [Bazel](https://bazel.build/),
39or [pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/).
40One new minor feature is added in this release: when a command flag argument
41contains dashes, these are implicitly converted to underscores.
42This is to allow those used to separate words of the flag name by dashes
43to do so, while the flag variable names are required to use underscores.
44
45Memory leaks reported by valgrind should be resolved by this release.
46This release fixes build errors with MS Visual Studio 2015.
47
48Please report any further issues with this release using the GitHub issue tracker.
49
50
5124 March 2015
52-------------
53
54I've just released gflags 2.1.2.
55
56This release completes the namespace change fixes. In particular,
57it restores binary ABI compatibility with release version 2.0.
58The deprecated "google" namespace is by default still kept as
59primary namespace while symbols are imported into the new "gflags" namespace.
60This can be overridden using the CMake variable GFLAGS_NAMESPACE.
61
62Other fixes of the build configuration are related to the (patched)
63CMake modules FindThreads.cmake and CheckTypeSize.cmake. These have
64been removed and instead the C language is enabled again even though
65gflags is written in C++ only.
66
67This release also marks the complete move of the gflags project
68from Google Code to GitHub. Email addresses of original issue
69reporters got lost in the process. Given the age of most issue reports,
70this should be negligable.
71
72Please report any further issues using the GitHub issue tracker.
73
74
7530 March 2014
76-------------
77
78I've just released gflags 2.1.1.
79
80This release fixes a few bugs in the configuration of gflags\_declare.h
81and adds a separate GFLAGS\_INCLUDE\_DIR CMake variable to the build configuration.
82Setting GFLAGS\_NAMESPACE to "google" no longer changes also the include
83path of the public header files. This allows the use of the library with
84other Google projects such as glog which still use the deprecated "google"
85namespace for the gflags library, but include it as "gflags/gflags.h".
86
8720 March 2014
88-------------
89
90I've just released gflags 2.1.
91
92The major changes are the use of CMake for the build configuration instead
93of the autotools and packaging support through CPack. The default namespace
94of all C++ symbols is now "gflags" instead of "google". This can be
95configured via the GFLAGS\_NAMESPACE variable.
96
97This release compiles with all major compilers without warnings and passed
98the unit tests on  Ubuntu 12.04, Windows 7 (Visual Studio 2008 and 2010,
99Cygwin, MinGW), and Mac OS X (Xcode 5.1).
100
101The SVN repository on Google Code is now frozen and replaced by a Git
102repository such that it can be used as Git submodule by projects. The main
103hosting of this project remains at Google Code. Thanks to the distributed
104character of Git, I can push (and pull) changes from both GitHub and Google Code
105in order to keep the two public repositories in sync.
106When fixing an issue for a pull request through either of these hosting
107platforms, please reference the issue number as
108[described here](https://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control).
109For the further development, I am following the
110[Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)
111with feature branch names prefixed by "feature/" and bugfix branch names
112prefixed by "bugfix/", respectively.
113
114Binary and source [packages](https://github.com/schuhschuh/gflags/releases) are available on GitHub.
115
116
11714 January 2014
118---------------
119
120The migration of the build system to CMake is almost complete.
121What remains to be done is rewriting the tests in Python such they can be
122executed on non-Unix platforms and splitting them up into separate CTest tests.
123Though merging these changes into the master branch yet remains to be done,
124it is recommended to already start using the
125[cmake-migration](https://github.com/schuhschuh/gflags/tree/cmake-migration) branch.
126
127
12820 April 2013
129-------------
130
131More than a year has past since I (Andreas) took over the maintenance for
132`gflags`. Only few minor changes have been made since then, much to my regret.
133To get more involved and stimulate participation in the further
134development of the library, I moved the project source code today to
135[GitHub](https://github.com/schuhschuh/gflags).
136I believe that the strengths of [Git](http://git-scm.com/) will allow for better community collaboration
137as well as ease the integration of changes made by others. I encourage everyone
138who would like to contribute to send me pull requests.
139Git's lightweight feature branches will also provide the right tool for more
140radical changes which should only be merged back into the master branch
141after these are complete and implement the desired behavior.
142
143The SVN repository remains accessible at Google Code and I will keep the
144master branch of the Git repository hosted at GitHub and the trunk of the
145Subversion repository synchronized. Initially, I was going to simply switch the
146Google Code project to Git, but in this case the SVN repository would be
147frozen and force everyone who would like the latest development changes to
148use Git as well. Therefore I decided to host the public Git repository at GitHub
149instead.
150
151Please continue to report any issues with gflags on Google Code. The GitHub project will
152only be used to host the Git repository.
153
154One major change of the project structure I have in mind for the next weeks
155is the migration from autotools to [CMake](http://www.cmake.org/).
156Check out the (unstable!)
157[cmake-migration](https://github.com/schuhschuh/gflags/tree/cmake-migration)
158branch on GitHub for details.
159
160
16125 January 2012
162---------------
163
164I've just released gflags 2.0.
165
166The `google-gflags` project has been renamed to `gflags`.  I
167(csilvers) am stepping down as maintainer, to be replaced by Andreas
168Schuh.  Welcome to the team, Andreas!  I've seen the energy you have
169around gflags and the ideas you have for the project going forward,
170and look forward to having you on the team.
171
172I bumped the major version number up to 2 to reflect the new community
173ownership of the project.  All the [changes](ChangeLog.txt)
174are related to the renaming.  There are no functional changes from
175gflags 1.7.  In particular, I've kept the code in the namespace
176`google`, though in a future version it should be renamed to `gflags`.
177I've also kept the `/usr/local/include/google/` subdirectory as
178synonym of `/usr/local/include/gflags/`, though the former name has
179been obsolete for some time now.
180
181
18218 January 2011
183---------------
184
185The `google-gflags` Google Code page has been renamed to
186`gflags`, in preparation for the project being renamed to
187`gflags`.  In the coming weeks, I'll be stepping down as
188maintainer for the gflags project, and as part of that Google is
189relinquishing ownership of the project; it will now be entirely
190community run.  The name change reflects that shift.
191
192
19320 December 2011
194----------------
195
196I've just released gflags 1.7.  This is a minor release; the major
197change is that `CommandLineFlagInfo` now exports the address in memory
198where the flag is located.  There has also been a bugfix involving
199very long --help strings, and some other minor [changes](ChangeLog.txt).
200
20129 July 2011
202------------
203
204I've just released gflags 1.6.  The major new feature in this release
205is support for setting version info, so that --version does something
206useful.
207
208One minor change has required bumping the library number:
209`ReparseCommandlineFlags` now returns `void` instead of `int` (the int
210return value was always meaningless).  Though I doubt anyone ever used
211this (meaningless) return value, technically it's a change to the ABI
212that requires a version bump.  A bit sad.
213
214There's also a procedural change with this release: I've changed the
215internal tools used to integrate Google-supplied patches for gflags
216into the opensource release.  These new tools should result in more
217frequent updates with better change descriptions.  They will also
218result in future `ChangeLog` entries being much more verbose (for better
219or for worse).
220
221See the [ChangeLog](ChangeLog.txt) for a full list of changes for this release.
222
22324 January 2011
224---------------
225
226I've just released gflags 1.5.  This release has only minor changes
227from 1.4, including some slightly better reporting in --help, and
228an new memory-cleanup function that can help when running gflags-using
229libraries under valgrind.  The major change is to fix up the macros
230(`DEFINE_bool` and the like) to work more reliably inside namespaces.
231
232If you have not had a problem with these macros, and don't need any of
233the other changes described, there is no need to upgrade.  See the
234[ChangeLog](ChangeLog.txt) for a full list of changes for this release.
235
23611 October 2010
237---------------
238
239I've just released gflags 1.4.  This release has only minor changes
240from 1.3, including some documentation tweaks and some work to make
241the library smaller.  If 1.3 is working well for you, there's no
242particular reason to upgrade.
243
2444 January 2010
245--------------
246
247I've just released gflags 1.3.  gflags now compiles under MSVC, and
248all tests pass.  I **really** never thought non-unix-y Windows folks
249would want gflags, but at least some of them do.
250
251The major news, though, is that I've separated out the python package
252into its own library, [python-gflags](http://code.google.com/p/python-gflags).
253If you're interested in the Python version of gflags, that's the place to
254get it now.
255
25610 September 2009
257-----------------
258
259I've just released gflags 1.2.  The major change from gflags 1.1 is it
260now compiles under MinGW (as well as cygwin), and all tests pass.  I
261never thought Windows folks would want unix-style command-line flags,
262since they're so different from the Windows style, but I guess I was
263wrong!
264
265The other changes are minor, such as support for --htmlxml in the
266python version of gflags.
267
26815 April 2009
269-------------
270
271I've just released gflags 1.1.  It has only minor changes fdrom gflags
2721.0 (see the [ChangeLog](ChangeLog.txt) for details).
273The major change is that I moved to a new system for creating .deb and .rpm files.
274This allows me to create x86\_64 deb and rpm files.
275
276In the process of moving to this new system, I noticed an
277inconsistency: the tar.gz and .rpm files created libraries named
278libgflags.so, but the deb file created libgoogle-gflags.so.  I have
279fixed the deb file to create libraries like the others.  I'm no expert
280in debian packaging, but I believe this has caused the package name to
281change as well.  Please let me know (at
282[[mailto:google-gflags@googlegroups.com](mailto:google-gflags@googlegroups.com)
283google-gflags@googlegroups.com]) if this causes problems for you --
284especially if you know of a fix!  I would be happy to change the deb
285packages to add symlinks from the old library name to the new
286(libgoogle-gflags.so -> libgflags.so), but that is beyond my knowledge
287of how to make .debs.
288
289If you've tried to install a .rpm or .deb and it doesn't work for you,
290let me know.  I'm excited to finally have 64-bit package files, but
291there may still be some wrinkles in the new system to iron out.
292
2931 October 2008
294--------------
295
296gflags 1.0rc2 was out for a few weeks without any issues, so gflags
2971.0 is now released.  This is much like gflags 0.9.  The major change
298is that the .h files have been moved from `/usr/include/google` to
299`/usr/include/gflags`.  While I have backwards-compatibility
300forwarding headeds in place, please rewrite existing code to say
301```
302   #include <gflags/gflags.h>
303```
304instead of
305```
306   #include <google/gflags.h>
307```
308
309I've kept the default namespace to google.  You can still change with
310with the appropriate flag to the configure script (`./configure
311--help` to see the flags).  If you have feedback as to whether the
312default namespace should change to gflags, which would be a
313non-backwards-compatible change, send mail to
314`google-gflags@googlegroups.com`!
315
316Version 1.0 also has some neat new features, like support for bash
317commandline-completion of help flags.  See the [ChangeLog](ChangeLog.txt)
318for more details.
319
320If I don't hear any bad news for a few weeks, I'll release 1.0-final.
321