diff options
Diffstat (limited to 'extern/libmv/third_party/gflags/README.md')
| -rw-r--r-- | extern/libmv/third_party/gflags/README.md | 270 |
1 files changed, 270 insertions, 0 deletions
diff --git a/extern/libmv/third_party/gflags/README.md b/extern/libmv/third_party/gflags/README.md new file mode 100644 index 00000000000..79bd2028603 --- /dev/null +++ b/extern/libmv/third_party/gflags/README.md @@ -0,0 +1,270 @@ +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. |