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