The first element in the GFLAGS_NAMESPACE list is used as primary/default namespace. The symbols are then imported from this primary namespace into each of the other alternative namespaces with the using keyword. This is in particular used to maintain backwards compatibility with previous gflags library versions that used the "google" namespace instead of the new default "gflags" namespace.
Expose as few system variables as possible through public interface.
Perform STRIP_FLAGS_HELP test using CMake instead of Bash.
Change file path separator used by gflags_reporting.cc to backslash on Windwos.
* gflags: version 2.0
* Changed the 'official' gflags email in setup.py/etc
* Renamed google-gflags.sln to gflags.sln
* Changed copyright text to reflect Google's relinquished ownership
git-svn-id: https://gflags.googlecode.com/svn/trunk@74 6586e3c6-dcc4-952a-343f-ff74eb82781d
remove the 'categories' field from CommandLineFlagInfo. (Note
the code to fill this field was removed from
FillComandLineFlagInfo previously, so it's been an empty
string for some time now.)
R=ncalvin
DELTA=1 (0 added, 1 deleted, 0 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3616
git-svn-id: https://gflags.googlecode.com/svn/trunk@70 6586e3c6-dcc4-952a-343f-ff74eb82781d
I left in the old FlagRegisterer constructor.
I also left in 'categories' in CommandLineFlagInfo for now,
though I never use it. I doubt anyone else does either, but I
want to minimize the number of ways this rollback can break
the build. I will remove it in a subsequent CL.
R=ncalvin
DELTA=121 (28 added, 55 deleted, 38 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3574
git-svn-id: https://gflags.googlecode.com/svn/trunk@68 6586e3c6-dcc4-952a-343f-ff74eb82781d
reports that the error isn't always getting flushed on
cygwin. So do that explicitly.
R=desovski
DELTA=1 (1 added, 0 deleted, 0 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3140
git-svn-id: https://gflags.googlecode.com/svn/trunk@64 6586e3c6-dcc4-952a-343f-ff74eb82781d
FlagRegisterer.
Because this backwards-compatible API is intended to be
short-lived, I did it in the simplest, least invasive way
possible, which involved cutting-and-pasting.
R=ncalvin,jkline
DELTA=27 (27 added, 0 deleted, 0 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3065
git-svn-id: https://gflags.googlecode.com/svn/trunk@62 6586e3c6-dcc4-952a-343f-ff74eb82781d
Add support for flag categories.
In this CL, all you can do is set categories in the DEFINE_*
macros and then retrieve them via GetCommandLineFlagInfo and
similar.
In future CLs, we will start to give some semantic meaning to
particular flag values, as described in the designdoc. In
particular, we will start to use flag categories to revamp
--help output.
Implementation-wise: to keep categories an optional macro
argument, I had to use __VA_ARGS__, which means future gflags
releases will no longer work with MSVC 7.1. We're at MSVC 10
now, so I'm pretty much ok with that.
The downside of __VA_ARGS__ is there is no error if you
specify more args after the ones we expect. To get around
that, I only use __VA_ARGS_ in this idiom:
static const OptionalDefineArgs var = { __VA_ARGS__ };
The new OptionalDefineArgs struct defines all the args that
may be optionally specified in the DEFINE_* macros. For now,
that's only the 'categories' arg, though in theory more could be
added later.
R=titus,ncalvin
DELTA=92 (54 added, 3 deleted, 35 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3057
git-svn-id: https://gflags.googlecode.com/svn/trunk@61 6586e3c6-dcc4-952a-343f-ff74eb82781d
really long helpstring. Opensource gflags had a bug where we
were cutting off the output too soon; this test should protect
against such a thing.
R=nilton
DELTA=16 (16 added, 0 deleted, 0 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=2885
git-svn-id: https://gflags.googlecode.com/svn/trunk@58 6586e3c6-dcc4-952a-343f-ff74eb82781d
