1 files changed, 158 insertions, 0 deletions
diff --git a/extern/libmv/third_party/gflags/NEWS b/extern/libmv/third_party/gflags/NEWS
new file mode 100644
index 00000000000..ffc0127d91e
--- /dev/null
+++ b/extern/libmv/third_party/gflags/NEWS
@@ -0,0 +1,158 @@
+== 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
+[http://gflags.googlecode.com/svn/tags/gflags-2.0/ChangeLog changes]
+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
+[http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.7/ChangeLog changes].
+
+=== 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
+[http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.6/ChangeLog ChangeLog]
+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
+[http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.5/ChangeLog ChangeLog]
+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, [http://code.google.com/p/python-gflags 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
+[http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.1/ChangeLog ChangeLog]
+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
+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
+[http://code.google.com/p/google-gflags/source/browse/tags/gflags-1.0rc2/ChangeLog
+ChangeLog] for more details.
+
+If I don't hear any bad news for a few weeks, I'll release 1.0-final.