Fix compilation problems with deprecated macros

[j-rivero]

Workaround for issue #30.

Basically the solution is in commit f3f2d90ba402189257502a68d2da14163fbf56cd: duplicate the log function with a new name, mark it as deprecated and use it in the deprectated macros. I've leaved the deprecation warning on the console_bridge own code so we remember to remove it in the next releases.

I've implemented a basic test which just pretend to compile and helped to simulate downstream code. I've also enable the test in travis.

[scpeters]

Actually that console_bridge_deprecated() statement is making travis fail since it has -Werror set.

[j-rivero]

Actually that console_bridge_deprecated() statement is making travis fail since it has -Werror set.

No problem, removed.

@jspricke can you confirm that the fix works for you?

[scpeters]

+1

waiting for confirmation from @jspricke

[jspricke]

I've tested this patch on top of the console_bridge 0.3-3 currently in Debian unstable and compilation of ros-comm and a few others worked fine.

I'm fine with the patch, except, that I would vote against including gtest in here, but rather depend on it.

[scpeters]

@j-rivero have we ever tried using find_package to find libgtest-dev?

[jspricke]

Hi, any news on this? Regarding gtest, we do it like this in PCL: https://github.com/PointCloudLibrary/pcl/blob/a654fe4188382416c99322cafbd9319c59a7355c/cmake/Modules/FindGtest.cmake.

[scpeters]

How do you find the gtest source on osx? I don't know of a homebrew formula that installs the gtest source

[jspricke]

No idea, I don't use Apple. But I guess you can just put the sources somewhere and point cmake to it.

[scpeters]

I just posted a question on the homebrew mailing list:

• https://groups.google.com/forum/#!topic/homebrew-discuss/Y8evUFkDrrw

[scpeters]

Embedding gtest seems to be the best cross-platform way to use it, so I'm going to merge this as-is.