Open GoogleCodeExporter opened 8 years ago
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
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:
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
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
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
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
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
Original issue reported on code.google.com by
alias...@gmail.com
on 15 Nov 2009 at 6:53