Import symbols into google namespace to maintain backwards compatibility

[GoogleCodeExporter]

As the C++ namespace of the gflags functions and types has changed from 
"google" to "gflags", it requires the update of existing project that make use 
of it, in particular other Google projects such as glog. Setting the CMake 
variable GFLAGS_NAMESPACE is possible for single users, but not for the 
creation of binary packages of gflags for common Linux distributions.

Therefore, to maintain backwards compatibility, I suggest to add a 
gflags_google.h file which contains the following code:

namespace google {

using gflags::FlagRegisterer;
// ....

}

with a using statement for each function and type that existed before version 
2.1 in the google namespace.

Original issue reported on code.google.com by andreas....@gmail.com on 2 May 2014 at 10:09

[GoogleCodeExporter]

This has been implemented. In fact, any number of alternative namespaces can be 
configured next to the default/primary namespace using the GFLAGS_NAMESPACE 
CMake variable.

See commit 659b440f of the feature/#83-alternative-namespace branch.

Original comment by andreas....@gmail.com on 2 May 2014 at 2:00

• Changed state: Testing

[GoogleCodeExporter]

Link to commit: 
https://code.google.com/p/gflags/source/detail?r=659b440f9e403c9080eb304efc53b93
8c63cbe47&name=feature/#83-alternative-namespace

Original comment by andreas....@gmail.com on 2 May 2014 at 2:02

[GoogleCodeExporter]

This branch works well for me; I can link glog to it and I don't have to change 
existing code. Please include it in a future release!

Original comment by carles.f...@gmail.com on 18 May 2014 at 11:17

[GoogleCodeExporter]

Hi Carles, thanks for the feedback. I will make another patch release available 
soon which hopefully concludes the transition to the new build system 
configuration and namespace.

Original comment by andreas....@gmail.com on 18 May 2014 at 11:34

[GoogleCodeExporter]

Great! Thanks for your work.

Original comment by carles.f...@gmail.com on 19 May 2014 at 12:08

[GoogleCodeExporter]

I'm running into issues compiling glog because of this (running fresh built 
2.1.1) - any chance someone could post how I'd set the CMake variable 
GFLAGS_NAMESPACE so I can workaround the issue? Or is 2.1.2 release imminent?

Original comment by cputt...@gmail.com on 7 Jul 2014 at 6:04

[GoogleCodeExporter]

Thanks for bumping it up... soon was meant to be sooner ;)

Regarding the CMake settings of 2.1.1, you will need to change GFLAGS_NAMESPACE 
to "google" and make sure that GFLAGS_INCLUDE_DIR is "gflags". See issue #80.

Original comment by andreas....@gmail.com on 9 Jul 2014 at 1:19

[GoogleCodeExporter]

I've just had a chance to return to this. Not knowing anything about cmake, 
I've edited CMakeLists.txt & changed the line

set (GFLAGS_NAMESPACE   "${PACKAGE_NAME}" CACHE STRING "C++ namespace 
identifier of gflags library.")

to

set (GFLAGS_NAMESPACE   "google" CACHE STRING "C++ namespace identifier of 
gflags library.")

Then built and installed as per normal instructions. However when I try to 
compile glog I get a fail, with the error message

/usr/local/lib/libgflags.a: could not read symbols: Bad value

I guess I'm doing something wrong still...

Original comment by cputt...@gmail.com on 26 Jul 2014 at 7:37

[GoogleCodeExporter]

For projects that use a system-installed gflags development package this is 
still more or less a problem. Since you don't have control of the CMake 
GFLAGS_NAMESPACE variable, and the config.h will not be distributed, there's no 
way to determine gflags version and namespace.

This could export a define for the namespace, and make sure that ends up in 
gflags.h. How about:

#define GFLAGS_NAMESPACE gflags

Original comment by te...@prosauce.org on 3 Nov 2014 at 4:17

[GoogleCodeExporter]

Thanks for the suggestion. As a matter of fact, such define was already added 
by commit a93de007 
(https://code.google.com/p/gflags/source/detail?r=a93de007a65eea5f0eea1eb830788d
bdb7c17112&name=feature/#83-alternative-namespace) in a feature branch.

Original comment by andreas....@gmail.com on 9 Nov 2014 at 9:06