Configure and install CMake package configuration file to help find_package locate the gflags package.

Move public header files to src/ subdirectory. Copy them to <prefix>/include/<ns>/ upon installation.

Remove build tool related files, operating system packages, and move unit tests to separate subdirectory.

git-svn-id: https://gflags.googlecode.com/svn/trunk@84 6586e3c6-dcc4-952a-343f-ff74eb82781d

git-svn-id: https://gflags.googlecode.com/svn/trunk@83 6586e3c6-dcc4-952a-343f-ff74eb82781d

git-svn-id: https://gflags.googlecode.com/svn/trunk@82 6586e3c6-dcc4-952a-343f-ff74eb82781d

git-svn-id: https://gflags.googlecode.com/svn/trunk@81 6586e3c6-dcc4-952a-343f-ff74eb82781d

Fix deprecation warnings of VC++ regarding strdup and unlink. Add solution files for VS 2010 and VS 2012.

git-svn-id: https://gflags.googlecode.com/svn/trunk@80 6586e3c6-dcc4-952a-343f-ff74eb82781d

git-svn-id: https://gflags.googlecode.com/svn/trunk@79 6586e3c6-dcc4-952a-343f-ff74eb82781d

Use project name (gflags) within include guards to avoid conflict with gperftools as reported by chen3feng (issue #62, http://code.google.com/p/gflags/issues/detail?id=62).

git-svn-id: https://gflags.googlecode.com/svn/trunk@78 6586e3c6-dcc4-952a-343f-ff74eb82781d

Fix "invalid suffix on literal; C++11 requires a space between literal and identifier" errors as reported by http://code.google.com/p/gflags/issues/detail?id=54.

git-svn-id: https://gflags.googlecode.com/svn/trunk@77 6586e3c6-dcc4-952a-343f-ff74eb82781d

git-svn-id: https://gflags.googlecode.com/svn/trunk@76 6586e3c6-dcc4-952a-343f-ff74eb82781d

	* 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

	* google-gflags: version 1.7
	* Add CommandLineFlagInfo::flag_ptr pointing to current storage (musji)
	* PORTING: flush after writing to stderr, needed on cygwin
	* PORTING: Clean up the GFLAGS_DLL_DECL stuff better
	* Fix a bug in StringPrintf() that affected large strings (csilvers)
	* Die at configure-time when g++ isn't installed


git-svn-id: https://gflags.googlecode.com/svn/trunk@72 6586e3c6-dcc4-952a-343f-ff74eb82781d

Tested:
blaze test base:commandlineflags_unittest

R=csilvers
DELTA=4  (3 added, 0 deleted, 1 changed)


Revision created by MOE tool push_codebase.
MOE_MIGRATION=3791


git-svn-id: https://gflags.googlecode.com/svn/trunk@71 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

R=jkline,georgevdd
DELTA=27  (0 added, 27 deleted, 0 changed)


Revision created by MOE tool push_codebase.
MOE_MIGRATION=3609


git-svn-id: https://gflags.googlecode.com/svn/trunk@69 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

Add a 'flag_ptr' field to CommandLineFlagInfo that points to the current storage of the flag (i.e. &FLAGS_foo).

R=csilvers
DELTA=15  (15 added, 0 deleted, 0 changed)


Revision created by MOE tool push_codebase.
MOE_MIGRATION=3301


git-svn-id: https://gflags.googlecode.com/svn/trunk@67 6586e3c6-dcc4-952a-343f-ff74eb82781d

installed, but wasn't:
http://code.google.com/p/google-perftools/issues/detail?id=217

This turned out to be a bug in autoconf:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357378

The workaround is simple: check for CXX before checking for
CC.  This means that if g++ is installed but gcc isn't, we
won't die (at cc-checking time), but I tested, and the
configure script dies later.  In any case, it seems unlikely
someone would have a c++ compiler installed but not a c
compiler.

This fixes the 4 opensource projects I work on that are
susceptible to this.

R=iant
DELTA=1437  (694 added, 694 deleted, 49 changed)


Revision created by MOE tool push_codebase.
MOE_MIGRATION=3222


git-svn-id: https://gflags.googlecode.com/svn/trunk@66 6586e3c6-dcc4-952a-343f-ff74eb82781d

R=jkline,ncalvin
DELTA=28  (0 added, 27 deleted, 1 changed)


Revision created by MOE tool push_codebase.
MOE_MIGRATION=3169


git-svn-id: https://gflags.googlecode.com/svn/trunk@65 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

during 'normal' help output).

R=ncalvin
DELTA=3  (3 added, 0 deleted, 0 changed)


Revision created by MOE tool push_codebase.
MOE_MIGRATION=3066


git-svn-id: https://gflags.googlecode.com/svn/trunk@63 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

NOTE: I'm checking this in just to have a record in source control of the idea.  We've decided for now it doesn't make sense to go forward with flag categories -- and the __VA_ARGS__ for macros has caused lots of problems with uncaught accidental commas, already -- so a future commit will back this out.  (Actually, it's all a series of commits, for annoying technical reasons.)

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

R=jyrki
DELTA=33  (0 added, 27 deleted, 6 changed)


Revision created by MOE tool push_codebase.
MOE_MIGRATION=3016


git-svn-id: https://gflags.googlecode.com/svn/trunk@60 6586e3c6-dcc4-952a-343f-ff74eb82781d