gflags: Google's command line flag library, now maintained as a community project
The gflags package contains a C++ library that implements commandline flags processing. It includes built-in support for standard types such as string and the ability to define flags in the source file in which they are used. Online documentation available at:
At a glance
- What is it?
- The C++ flags library Google wrote and then handed off. It still does one job well across Bazel, CMake and pkg-config, but the README is explicit that new features are not planned and points you at Abseil first.
- Who is it for?
- gflags is a solved problem that is still solved well: define a flag where you use it, get typed values, string conversion, and the built-in help output, with consumption paths through Bazel, CMake and pkg-config that all work. What has changed is who owns it.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 77 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Google wrote it, released it, and then stopped shipping it
The most useful thing the gflags README does is tell you not to use gflags. Not in those words, but the opening paragraph explains that this is an open-source community project developed and originally released by Google and no longer maintained by Google. It notes that an internal fork was re-released as part of Abseil, and that if you are using Abseil, the maintainers recommend Abseil's flags library instead.
That recommendation is more than a diplomatic note. Abseil is where Google consolidated its open source C++ work, and gflags was one of the libraries folded in. So the version of gflags you can install from Google today is, in effect, a snapshot of an internal fork at the moment it was donated. The subsequent history is community maintenance: the README records Andreas taking over in April 2013 and moving the source to GitHub because, in his own words, few minor changes had been made and he wanted to stimulate participation.
The practical consequence is a library with a stable API and a conservative roadmap. Version 2.1 in March 2014 moved the build from autotools to CMake and changed the default C++ namespace from `google` to `gflags`, which was the one genuinely disruptive change in the project's history. Everything after that has been a maintenance line.
Reading the release history as the project's own status report
The release list is unusually honest about what this project is, mostly by showing the gaps. Version 2.2.2 came in November 2018, with a v2.3.0 following on 06 December 2025, and a v2.3.1 on 2026-07-22. A seven-year gap between 2.2.2 and 2.3.0 is the single most informative fact about gflags, and no single explanation covers it.
What came in 2.3.0 was build system work. Support for Bzlmod, added to prepare for Bazel 9. CMake 4.0 and BlackBerry QNX support. Fixes for undefined behavior in option processing. Migration of the CI infrastructure to GitHub Actions. Version 2.3.1, by the same measure, is three pull requests: pointing the test workflow at `main` instead of `master`, adding a GitHub Actions workflow to build with Bazel, and QNX support in Bazel plus further Bazel 9 fixes. One of those came from a first-time contributor, which matches the README's stated model of community maintenance.
The 2.3.0 changelog also shows the kind of quiet hygiene work that only happens on a codebase somebody still owns. A fix so `GFLAGS_*` variables take precedence in `gflags_define`. Removal of unreachable code. A change to avoid a no-match message when `STRIP_FLAG_HELP` has been set. clang-tidy fixes. Removal of a visibility attribute where it does not apply. Nothing in there changes how you write a flag, which is the point.
The last push was on 2026-07-25, days before the 2.3.1 tag, so the repository is being worked on. Active and adding features are different claims, and for gflags only the first one is true.
Defining a flag next to the code that reads it
Strip away the build system questions and the library is small. The repository description says it implements command line flags processing for C++, with built-in support for standard types such as string, and the ability to define flags in the source file in which they are used.
That second capability is the design decision worth understanding. The usual complaint about flag libraries is that the declaration lives in one place and the use lives in another, so a rename breaks the build in a file you were not editing. gflags lets you declare a flag at the point of use, in the translation unit that reads it. For a codebase with many optional behaviours spread across subsystems, that means the full set of tunables is discoverable by reading the code rather than by reading a separate definitions file.
The library also handles the mundane parts that every CLI needs: converting string arguments from the command line into typed values, rejecting values that do not parse, and generating the help output that users actually depend on when they forget a flag name. The `STRIP_FLAG_HELP` macro that appeared in the 2.3.0 changelog is the knob for the last of those, letting a build drop help strings where binary size matters.
The namespace history matters if you are reading older code or mixing libraries. Symbols moved from the `google` namespace to `gflags` in 2.1, the build variable `GFLAGS_NAMESPACE` selects which one is primary, and 2.1.2 restored binary ABI compatibility with 2.0 after that transition by keeping the old namespace as the default while importing symbols into the new one. Code written against gflags in 2013 and code written against it today can still link.
Three build systems, and the 2016 release that made all three work
The repository tree is a better summary of modern gflags than the README is: a `BUILD` file and `WORKSPACE` for the older Bazel workflow, `MODULE.bazel` and `MODULE.bazel.lock` plus a `.bazelversion` for Bzlmod, `CMakeLists.txt` with a `cmake/` directory beside it, and `bazel/` for Bazel-specific build logic. There are also `src/`, `test/`, `doc/`, `INSTALL.md`, `RELEASE.md`, `ChangeLog.txt`, `COPYING.txt` and `AUTHORS.txt`.
Version 2.2.0 in November 2016 is the release that made this work as a dependency rather than as a vendored source tree. It added support for consuming gflags as an external dependency not only from CMake but also from Bazel or pkg-config. If you are adding it to a project today, that release note is the reason the integration is a two-line change in any of the three build systems rather than a project.
Two details from the release history will save time if you hit them. The 2.2.0 notes mention that when a command line flag argument contains dashes, these are implicitly converted to underscores, so a flag declared as `my_flag_name` can be passed as `--my-flag-name`. And 2.2.2, from 2018, fixed Bazel users' problem with `config.h` leaking into global include paths, and prefixed the exported CMake targets with `gflags::` while keeping the unprefixed names working so dependent projects did not have to change.
The 2.3.0 changelog adds vcpkg installation instructions and mentions Homebrew in the INSTALL file, so the packaged routes exist for Windows and macOS developers as well as for Linux distributions.
Why the Abseil comparison is the only comparison that matters
Worth stating plainly, because most articles about gflags pretend this question does not arise. Abseil's flags library is not a competing third-party package; it is the same library, released by the same organisation, with the same author lineage, as part of a larger collection that Google now actively develops. Choosing `absl::flags` over gflags is choosing Google's current distribution of the idea over Google's former one.
The differences follow from the packaging. Abseil is distributed as part of a larger dependency you pull in whole, which means you take its build rules, its minimum C++ standard and its release cadence along with it. gflags is distributed alone, so it is the cheaper dependency for a project that wants nothing else from Abseil. The trade is real and it runs both ways.
Where gflags is clearly behind is in new capability. Because the README says feature additions are not currently planned and depend on the open-source community submitting pull requests, a flag type, a new parsing behaviour or a build system nobody at Google uses will not appear on a roadmap. Abseil receives those. If you are writing a new command line tool and need unusual flag behaviour, the cost of the switch is lower now than it will be after you have wired gflags through three build files.
Where gflags is not behind is stability. A fifteen-year-old API that has not changed meaningfully since 2014, with a namespace transition handled for backwards compatibility, is a predictable dependency. For a long-lived service that will not be rewritten, predictable beats current.
What the README deliberately leaves out
The README is not a tutorial and it is not trying to be. It opens with a link to the documentation at gflags.github.io, states the maintenance and licensing situation, and then does something unusual for a library of its age: it appends the entire release history as prose, each release dated and described in a paragraph, going back to the 2013 handover. There are no install commands in it and no example of declaring a flag.
Everything practical lives elsewhere in the repository and on the documentation site. INSTALL.md covers the installation routes and was reordered in 2.3.0 to mention Homebrew, with vcpkg instructions added in the same release. `doc/` holds the reference material. RELEASE.md covers how the maintainer cuts a release, which is useful if you want to understand the tagging and changelog conventions rather than only consume them.
The licensing is the simplest thing about the project: BSD-3-Clause, stated in the repository description and covered by COPYING.txt at the root. There is no copyleft obligation and no CLA to negotiate, which is worth noting precisely because Abseil, the library you are being pointed toward, also uses Apache 2.0 and is similarly permissive.
One last practical detail. The repository's default branch is `main`, and the 2.3.1 release notes include a commit pointing the test workflow at `main` instead of `master`. If you have an old fork or a CI job pinned to `master`, that is exactly the kind of small thing that breaks quietly.
Editorial conclusion
gflags is a solved problem that is still solved well: define a flag where you use it, get typed values, string conversion, and the built-in help output, with consumption paths through Bazel, CMake and pkg-config that all work. What has changed is who owns it. The README states that this is a community project no longer maintained by Google, that it will mainly receive minor maintenance releases, and that feature additions are not currently planned. That makes the choice straightforward. If you are starting something new and already depend on Abseil, use `absl::flags` and the question is closed. If you have an existing Bazel or CMake build that links gflags, the 2.3.x line keeps the build working, including Bzlmod and CMake 4.0 support added in v2.3.0. Start reading at INSTALL.md and doc/ in the repository, and treat gflags.github.io as the reference for flag semantics.
Frequently asked questions
Is gflags still maintained by Google?
No. The README states that this is an open-source community project developed and originally released by Google, but no longer maintained by Google. The last push was on 2026-07-25 and version 2.3.1 was published on 2026-07-22, so the repository receives community maintenance releases, but the README says feature additions are not currently planned.
Should I use gflags or Abseil's flags library instead?
If you already depend on Abseil, the README explicitly recommends Abseil's flags library, since an internal fork of gflags was re-released as part of Abseil. Choosing gflags makes sense when you want the flag library alone without pulling in all of Abseil, and you value its long-stable API over newer capability.
How do I add gflags to a project as a dependency?
Since version 2.2.0, gflags supports being consumed as an external dependency from CMake, Bazel and pkg-config, rather than only being vendored. The repository ships a CMakeLists.txt with a cmake/ directory, a BUILD file with WORKSPACE, and MODULE.bazel with a lock file for Bzlmod. Package managers are covered too, with vcpkg instructions added in 2.3.0 and Homebrew mentioned in INSTALL.md.
What licence is gflags released under?
BSD-3-Clause. The repository description states the licence and the full text is in COPYING.txt at the root of the tree. There is no copyleft requirement and no contributor licence agreement to negotiate.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/gflags-gflags)