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