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