GNOME Bugzilla – Bug 599709
Add CMake files to the distribution
Last modified: 2016-03-20 21:27:56 UTC
Created attachment 146302 [details] CMakeLists.txt files and other CMake support files for building libsigc++ using cmake. Hi, I'd like to propose enhancing the build system by adding CMake support (in addition to autotools, of course) to libsigc++. This can be used to replace the M% Visual Studio project files since CMake can generate them automatically under Windows. I'm very new to this process so if I've done something in error, please forgive and correct me and I will be glad to fix it. I want to be able to contribute to this fine project I use practically on a daily basis! So far I have added CMake support for the following directories: sigc++/ examples/ TODO: docs/. tests/ and scripts/ Also there is a new folder called "cmake/" which contains "include" files if you will to make the compilation easier. Oh, and you can use the "cmake/Toolchain_mingw32.cmake" file to initiate a cross-platform build under Linux for MingW32. Pretty nifty. :-) I make this tarball using the 2.0.18 release, but I believe it can be adapted for the latest release without too much fuss. Please let me know if you need anything else from me to get this to work. So far I have tested this under Ubuntu 64 and Win32 using Microsoft Visual Studio 8.
Here are some further instructions that you may find useful: You can try making the archive by getting the latest cmake (2.6 will work). Untar the tarball into the 2.0.18 dist. Then at the command line type: $ cd ligsigc++2.0.18 $ mkdir BUILD $ cd BUILD $ cmake -G "Unix Makefiles" .. -DWANT_PREREQ_DIR:BOOL=FALSE $ make $ make install That will install into /usr/local by default. The CMAKE_INSTALL_PREFIX controls where it can be installed.
Created attachment 146307 [details] CMake files for libsigc++2.2.4 I've updated the license as well to make it LGPL and added appropriate headers. This version now works for the latest libsigc++ (2.2.4)
Also, the latest tarball contains support for the tests/ subdir.
Created attachment 146309 [details] [review] Win32 MSVC patch for latest 2.2.4 tarball. Apply this patch in addition to the last tarball so it builds correctly under win32 msvc.
Created attachment 146310 [details] [review] Final patch...use this to patch libsigc++-2.2.4 and add all required cmake files. This obsoletes all the other uploads--sorry for the spam. Use this patch to add cmake support.
Thanks. Have you done any comparison between the existing MSVC++ files and the ones generated by CMake? I would like to avoid regressions. Also, is it any easier to maintain CMake files than to maintain the MSVC++ files? There's a lot of code in this patch.
Please respond.
"Also, is it any easier to maintain CMake files than to maintain the MSVC++ files? There's a lot of code in this patch." I believe I used the existing VC++ project files to make sure the proper switches are being set in CMakeLists.txt...having said that, I'm not too sure right now. I'd have to check. But it's a pretty straightforward thing to do, really. "Also, is it any easier to maintain CMake files than to maintain the MSVC++ files? There's a lot of code in this patch." I think so. If you maintain them separately, you are making extra work. With CMake, you can generate supported project files instead of maintaining them individually. This means once you've added a new file to the CMakeLists.txt, *all* of your supported platforms will build that file when you generate the project files on the respective platforms.
Whoops! Sorry for the cut and paste error.
I'd like to request this be implemented as well. I am working on a project that uses SigC++ and with the way it is now, there is nothing but trouble when trying to link to SigC++ using CMake. This may assist in fixing that issue. It will also come in handy because then you will not have to create a new solution file every time a new Visual Studio comes out, which will help when trying to link using a newer version of VS than on the current source code.
(In reply to comment #10) > there is nothing but trouble when > trying to link to SigC++ using CMake. If CMake can't use pkg-config then CMake has a problem. Apparently it shouldn't be hard, though it was for me: http://www.murrayc.com/blog/permalink/2009/10/28/trying-qmake-and-cmake/ If libsigc++ needs a CMake "Find" module then we can add that, but that shouldn't require that we actually use CMake to build libsigc++.
Alright, I mis-interpreted the point of this ticket a bit. I think it would be nice to see that findlibsigc file. I've been attempting for at least a few months to get one working, however every time I do, the linker breaks because it interprets the .0 in the file name as a file extension. And yes, I have opened up a tracker ticket on that over at CMake as well. However, I should say this. Having CMake implemented in the build process would cut back on issues involving moving between Visual Studio versions. For Example, there is no VS10 solution for SigC++ yet, however CMake supported VS10 since it was in testing. This may help with preventing linker errors caused by compiling the library in one version and what your trying to do in another version, otherwise you get runtime errors galore. It should also reduce the long term workload of the developers here in that you have less to worry about in regards to supporting new versions of visual studio and project files for various IDEs, as CMake supports most if not all of them quickly.
(In reply to comment #12) > And yes, I have > opened up a tracker ticket on that over at CMake as well. Could you paste the URL here, please. > However, I should say this. Having CMake implemented in the build process would > cut back on issues involving moving between Visual Studio versions. For > Example, there is no VS10 solution for SigC++ yet, I believe there is now, in the regular gtkmm installer. I'm unlikely to bother support a whole CMake build system until someone can even make it easy to use libsigc++ _from_ CMake.
Created attachment 174761 [details] cmake findsigcxx for finding sigc++
That was sourced from here: http://www.cmake.org/pipermail/cmake/2008-December/026068.html with slight modifications to make it work properly.
Do you want to add that findsigcxx to libsigc++? I have no idea if that is appropriate in CMake land. And does someone have a git patch to add the CMake build system for libsigc++ that they want me to add?
[Resetting QA Contact and Assignee to default - see bug 659799 for more info]
Peter, please respond to comment #16.
I believe that CMake now has better support for pkg-config so this bug would now be just about adding a CMake build system. I would now be open to adding this in parallel with the current autotools build, if someone would like to produce a suitable git patch against git master. I still don't like CMake but it is increasingly popular, so this could help us get contributions.
I just created a branch: https://git.gnome.org/browse/libsigcplusplus/log/?h=cmake-integration I'm going to finish Linux-related work (the most important thing: pkg-config integration), I could also test it on Windows platform. Feel free to contribute by uploading patches here, directly commiting to this branch, or post here any cmake-related ideas. When it is quite stable, I think we could merge it with master branch.
It seems we're not able to test current version with MSVC, since they're not supporting some modern C++ features[1], e.g. extended constexpr [1] https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table
(In reply to Marcin Kolny (IRC: loganek) from comment #21) > It seems we're not able to test current version with MSVC, since they're not > supporting some modern C++ features[1], e.g. extended constexpr > > [1] https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table That doesn't feel like a related problem. Please do open a separate bug for that. Maybe it can be worked around, or patched around. For instance, maybe by just @defining constexpr to nothing.
(In reply to Murray Cumming from comment #22) > (In reply to Marcin Kolny (IRC: loganek) from comment #21) > > It seems we're not able to test current version with MSVC, since they're not > > supporting some modern C++ features[1], e.g. extended constexpr > > > > [1] https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table > > That doesn't feel like a related problem. Please do open a separate bug for > that. Maybe it can be worked around, or patched around. For instance, maybe > by just @defining constexpr to nothing. I don't think resolving this problems will be very easy. Moreover, sigc++ requires compiler with C++14 support, so I don't think we shouldn't try to modify source code to be compatible with compilers with partial C++14 support. Anyway, you're right, it's not a place for this discussion. I've opened new bug: {{bugzilla|763537}}
I think I'm more or less done with the basic scenario. User is able to compile and install project, we're also providing both pkg-config file: g++ main.cc -std=c++1y $(pkg-config --cflags --libs sigc++-3.0) and CMake file, so you can use it in any cmake project: cmake_minimum_required (VERSION 3.4) project (sigctest) set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++1y") find_package(sigc++-3 CONFIG REQUIRED) add_executable(sigctest main.cc) target_link_libraries(sigctest sigc-3.0) That would be great, if someone could review my code. If everything is ok, then I don't see any reason to not merge it with master branch and do further development there. Autotools is still our primary build system, but if someone wants to use CMake, then it is already possible. Unfortunately, I couldn't test it with MSVC because of bug 763537
Thanks. Please go ahead and put this in master, where we can improve it even more. I had to reduce the required cmake version from 3.4 to 3.2 to use my cmake version. Is 3.4 really required? I did have this strange error, though the other tests seem to have built without problems: [ 95%] Built target test_tuple_start Scanning dependencies of target test_tuple_transform_each [ 96%] Building CXX object tests/CMakeFiles/test_tuple_transform_each.dir/test_tuple_transform_each.cc.o /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc: In function ‘constexpr void test_tuple_transform_each_constexpr()’: /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc:300:89: in constexpr expansion of ‘sigc::internal::tuple_transform_each(T&&) [with T_transformer = transform_as_constexpr_to_something; T = const std::tuple<int, double>&]()’ /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc:300:89: in constexpr expansion of ‘sigc::internal::detail::tuple_transform_each_impl<T_transformer, size_from_index>::tuple_transform_each(T_current&&, T_original&) [with T_current = const std::tuple<int, double>&; T_original = const std::tuple<int, double>; T_transformer = transform_as_constexpr_to_something; long unsigned int size_from_index = 2ul]((* & t))’ /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc:300:89: in constexpr expansion of ‘std::tuple_cat(_Tpls&& ...) [with _Tpls = {const std::tuple<>&, const std::tuple<char>&, const std::tuple<double>&}; <template-parameter-1-2> = void; typename std::__tuple_cat_result<_Tpls ...>::__type = std::tuple<char, double>](t_element, t_end)’ /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc:300:89: in constexpr expansion of ‘std::__tuple_concater<_Ret, std::_Index_tuple<_Is ...>, _Tp, _Tpls ...>::_S_do(_Tp&&, _Tpls&& ..., _Us&& ...) [with _Us = {}; _Ret = std::tuple<char, double>; long unsigned int ..._Is = {}; _Tp = const std::tuple<>&; _Tpls = {const std::tuple<char>&, const std::tuple<double>&}]((* & std::forward<const std::tuple<char>&>((* & __tpls#1))), (* & std::forward<const std::tuple<double>&>((* & __tpls#2))))’ /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc:300:89: in constexpr expansion of ‘std::__tuple_concater<_Ret, std::_Index_tuple<_Is ...>, _Tp, _Tpls ...>::_S_do(_Tp&&, _Tpls&& ..., _Us&& ...) [with _Us = {}; _Ret = std::tuple<char, double>; long unsigned int ..._Is = {0ul}; _Tp = const std::tuple<char>&; _Tpls = {const std::tuple<double>&}]((* & std::forward<const std::tuple<double>&>((* & __tps#1))))’ /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc:300:89: in constexpr expansion of ‘std::__tuple_concater<_Ret, std::_Index_tuple<_Is ...>, _Tp, _Tpls ...>::_S_do(_Tp&&, _Tpls&& ..., _Us&& ...) [with _Us = {const char&}; _Ret = std::tuple<char, double>; long unsigned int ..._Is = {0ul}; _Tp = const std::tuple<double>&; _Tpls = {}]((* & std::get<0ul, {char}>((* & std::forward<const std::tuple<char>&>((* & __tp))))))’ /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc:300:89: in constexpr expansion of ‘std::__tuple_concater<_Ret, std::_Index_tuple<> >::_S_do(_Us&& ...) [with _Us = {const char&, const double&}; _Ret = std::tuple<char, double>]((* & std::get<0ul, {double}>((* & std::forward<const std::tuple<double>&>((* & __tp))))))’ /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc:300:89: in constexpr expansion of ‘std::tuple<char, double>((* & std::forward<const char&>((* & __us#0))), (* & std::forward<const double&>((* & __us#1))))’ /usr/include/c++/5/tuple:606:30: in constexpr expansion of ‘((std::tuple<char, double>*)this)->std::tuple<char, double>::<anonymous>.std::_Tuple_impl<_Idx, _Head, _Tail ...>::_Tuple_impl<0ul, char, {double}>((* & __a1), (* & __a2))’ /usr/include/c++/5/tuple:206:44: in constexpr expansion of ‘((std::_Tuple_impl<0ul, char, double>*)this)->std::_Tuple_impl<0ul, char, double>::<anonymous>.std::_Head_base<_Idx, _Head, false>::_Head_base<0ul, char>((* & __head))’ /home/murrayc/checkout/gnome/libsigcplusplus_variadic/tests/test_tuple_transform_each.cc:300:89: error: accessing uninitialized member ‘std::tuple<char>::<anonymous>’ sigc::internal::tuple_transform_each<transform_as_constexpr_to_something>(t_original); ^ tests/CMakeFiles/test_tuple_transform_each.dir/build.make:54: recipe for target 'tests/CMakeFiles/test_tuple_transform_each.dir/test_tuple_transform_each.cc.o' fail
Please make sure that the autotools "make dist" puts the necessary files in that tarball, so people can use the CMake build when using libsigc++ from a tarball release.
(In reply to Murray Cumming from comment #25) > Thanks. Please go ahead and put this in master, where we can improve it even > more. Ok, done. > I had to reduce the required cmake version from 3.4 to 3.2 to use my cmake > version. Is 3.4 really required? I don't know what is minimum required version, but I wasn't able to test it on lower version. If you did test it with 3.2, and it works, then I think we can reduce this version to 3.2. > I did have this strange error, though the other tests seem to have built > without problems: It's really strange, and I wouldn't expect that it's because of cmake. I assume, it works with autotools? Do you use the same compiler? I can't reproduce this problem. (In reply to Murray Cumming from comment #26) > Please make sure that the autotools "make dist" puts the necessary files in > that tarball, so people can use the CMake build when using libsigc++ from a > tarball release. Yeah, good point. I completely forgot about it. I've added cmake files to dist.
Sorry, yes, I had just been using clang++ recently and hadn't tested the recent commits with g++. Many thanks for the CMake support. Please feel free to commit any improvements to the CMake files that you think of.
I've added this file about autotools and CMake: https://git.gnome.org/browse/libsigcplusplus/tree/README_build
I wonder, should this use GNUInstallDirs? https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html
AFAIK, CMAKE_INSTALL_LIBDIR contains lib64 for 64bit system, and autotools installs libraries to lib directory (at least in my case). Shouldn't we be consistent with the autotools?
I have no idea. I assume that GNUInstallDirs tries to do the right thing. I also assume that distro packages override that kind of stuff very often to do what they want. We don't really plan for people to use the CMake build for installing or for creating packages, so we might just try to do things as simply and correctly as possible until someone reports a bug about it.
Ok, I've included GNUInstallDirs to sigc++
I've also added some help to the documentation for people using libsigc++ from CMake, where we already had help for people using autotools. Please check that this is correct: https://git.gnome.org/browse/libsigcplusplus/tree/sigc++/sigc++.h#n84
Looks ok. I think we could also consider install sigc++-3Config.cmake and sigc++-3VersionConfig.cmake files in autotools. Then, instead of using pkg-config, developer could use find_package function in cmake build files.
What advantage would there be for people to use a nasty cmake find script over simple pkg-config? I find these cmake Find* scripts rather awful.
The only advantage is that instead of using pkgconfig in cmake file, developer could use sigc++ module. I think for now we can skip it, lets see how many people will use cmake at all.