Using CMake

[GoogleCodeExporter]

Port from autotools to CMake so it can be built easily on other platforms

Original issue reported on code.google.com by alias...@gmail.com on 15 Nov 2009 at 6:53

[GoogleCodeExporter]

I don't know CMake at all. If someone kindly contribute the first version of 
CMakeList.txt, I may be able to maintain it. I guess we can incorporate the 
file from 
libmv.

http://code.google.com/p/libmv/source/browse/trunk#trunk/src/third_party/glog

Original comment by shinichi...@gmail.com on 15 Nov 2009 at 3:20

[GoogleCodeExporter]

I have a sample CMakeLists.txt file you can use.

It requires the GTEST_ROOT environment variable defined.

It builds both the library and the unit tests (and register the tests)

It also does installation but I have problem with the header files (generated).

NOTE : As the header file are generated from associated *.in files, I don't 
have a
solution with CMake

Let me know how I can help enable glog to be build with CMake.

Original comment by Yue.Nich...@gmail.com on 9 May 2010 at 1:44

Attachments:

• CMakeLists.txt

[GoogleCodeExporter]

Thanks for the attempt to fix this issue! However, I'm not sure if it's worth 
adding 
this file for now because I'm not sure if this supports multiple environments.

It seems this doesn't detect environment yet? For example, it seems this 
doesn't add -
lgflags and -lunwind when they are available and this doesn't check the usage 
of 
ucontext. Should this work on Mac or Windows? If they are not implemented yet, 
is it 
easy to support such stuff?

Original comment by shinichi...@gmail.com on 27 May 2010 at 1:33

[GoogleCodeExporter]

Hi!
I'd like to help getting this to work.
Is it worth it or is anybody already working on it?

I would try to follow the path pointed at in this post: 
http://www.cmake.org/pipermail/cmake/2010-November/041052.html

cheers,

Sebastian

Original comment by sebi.k...@gmail.com on 10 Jul 2012 at 2:16

[GoogleCodeExporter]

Any updates on this?
I would really appreciate CMakeLists.txt for glog because I build it with my 
CMake project (currently using a bit ugly add_custom_command/add_custom_target 
hacks, which I'd like to get rid of).

I can spend some cycle on this, and I have converted a few multi-platform 
automake/autoconf projects to CMake projects before... but everytime I found 
that 100% translation is nearly impossible without bugging the person who wrote 
the original autotool scripts:-(

The most robust/efficient path is often the original implementer getting 
familiar with CMake and refactoring the project as a CMake project.

Some primer:
http://stackoverflow.com/questions/7132862/tutorial-for-converting-autotools-to-
cmake

I also found "am2cmake" was quite useful to start with although almost always I 
had to manually edit lots of things.

Original comment by hideaki.kimura@gmail.com on 25 Apr 2014 at 5:38

[GoogleCodeExporter]

As I didn't hear back, I was doing it myself... then found that there is 
already one (happy *and* sad moment):

https://github.com/THUKEG/saedb/tree/master/external/google-glog

How about to contact this author and merge it back to glog? It looks like a 
quite good port of glog's autoconf/automake scripts. A couple of notes, though:

 1. Now logging.h etc are NOT dynamically generated. The author put a set of already-generated versions of them. Only config.h goes through configure_file().
 2. The script uses a few internally-defined CMake commands. Changing them to builtin commands seems straightforward.
 3. fPIC by default. I also had to add this flag to use glog as a static library. I think the overhead of fPIC is negligible, so this seems to me the right thing to do.
 4. I'm not sure about correctness of a few lines in the CMakeLists.txt (eg "CHECK_FUNCTION_EXISTS(__builtin_expect HAVE___BUILTIN_EXPECT)"). I bet it's incorrect, but I might be wrong.

Regarding 1, another approach is to change all of "@ac_xxx" to HAVE_XXX etc and 
define them in config.h.in, then each header (eg logging.h) includes config.h 
at the beginning. I was actually taking that approach, but then I found this 
almost complete work, so I abandoned it.

Original comment by hideaki.kimura@gmail.com on 13 May 2014 at 5:11

[GoogleCodeExporter]

I would also love an official cmake support. specially considering gflags, a 
dependency does require cmake already and convinced myself that cmake was the 
way to go going forward (despite the somewhat strange filenames, command names 
etc...)

Original comment by ldemai...@gmail.com on 16 Dec 2014 at 3:49