Consider cmake
mjvankampen opened this issue · comments
I was wondering if you guys ever considered using cmake? This would remove the need to maintain all the makefiles and use a single cmakefile instead as most platform-specific stuff is handled by cmake itself or toolchain files.
I agree that cmake would be a good build system to adopt for our stuff. The included "waf" build is another option, but it's not as mainstream as cmake. I have looked into cmake a little bit and the Android Protolib build files do include some CMakefiles as part of the gradle scripts there. At the moment we are maintaining both the waf and the (yucky) Makefile.xxx approach. I appreciate the comment and would be happy to help someone navigate a contribution like that. I hope to set up some additional developer resources as adjunct to the GitHub repositories (now that we've established those) including a mailing list or equivalent and perhaps some means to manage a development roadmap "todo" list
Sounds good. One more question about the current setup. I see things like havedirfd macros. Is there any reason not to just check the POSIX feature test macro? Then you use existing stuff for this and your build system becomes a lot simpler IMHO.
I agree. A lot of those things are artifacts of how the code evolved. over time. I have thought about taking all of those things and putting checks like you describe in the include/protoDefs.h file to better automate and make the build more consistent. There is some fragility with the existing code where, if the macro definitions for the Protolib build and a dependent project (e.g., NORM, MGEN, etc) are not carefully aligned, bad code can be result. I've typically bundled the Protolib source code with those other projects and used Protolib as a source code toolkit more than a bona fide library. Hence the schizophrenia of "Protokit" versus "Protolib" you may notice in some of the naming. I appreciate the comments. As I have opportunity, I'm going look into setting up the Github project tools here and see if I can provide some better notes including a sort of roadmap for the items like you have mentioned to be tackled.
Thank you. I will try to review this sometime today.
I was able to spend a little time on this. I've started testing it with my default development platform which is MacOSX and had to fix a couple of minor things in the CMakeLists file. I got it to generate a Makefile that compiles the files but doesn't yet properly link the library. I haven't done much w/ CMake but should have it checked out within a few days depending on my schedule. I will accept your pull request once I get it a little more functional on a couple of platforms and the merge in my changes. Keep me updated if you do anything with it before then. Thanks for getting this started!
Uh oh! Makes sense though, I only tested on Windows and Ubuntu. I'll try with make as well. Used ninja up until now but I don't think it should matter.
Do you buid using make or cmake?
@bebopagogo I had to make some tweaks to build on CentOS 7 as well. Tried on FreeBSD 12 and made some progress but ran into issues compiling. Played a little on OpenBSD as well.
Do you have a list of platforms considered supported, or at leas that you want to call supported?
Case-sensitivity seemed to be an issue on CentOS (cmake3 package from EPEL for new enough CMake).
find_package(libxml2) needed to be find_package(LibXml2) and similarly find_package(wxwidgets) needed to be find_package(wxWidgets).
Looks like there's also a typo after the wxWidgets check where if(libxml2_FOUND) should be something like f(WXWINDOWS_FOUND).
On both FreeBSD and OpenBSD, I also found that this block had issues:
check_include_files( pcap.h HAVE_PCAP_H)
if(HAVE_PCAP_H)
list(APPEND PLATFORM_SOURCE_FILES ${COMMON}/pcapCap.cpp)
endif()
because where it sits in CMakeLists.txt, ${COMMON} hasn't been defined yet. Moving it right after set(COMMON src/common) resolved that.
@mjvk, @b00ga Sorry to be slow on this. The current situation has created more extra work for on other stuff than I had anticipated. With respect to platform support:
Linux, MacOSX, FreeBSD/OpenBSD, Windows, Android (the Android has its own CMakelists already for use with AndroidStudio). In addition to the usual 'make' build option I think it would be useful to use CMake to generate VisualStudio and Xcode IDE projects (maybe others, too). These are the ones I see current demand for ... there has been some embedded Linux with ARM support in the past where cross-compiler options have been useful ... but lower priority I think. I will try to catch up with you on this an bring in the CMake pull request as soon as I can.
for @mjvk, I built using 'make" with the Makefile generated by cmake ... I am a cmake newbie, so I didn't try to build that way if there's an option.
@mjvk, @b00ga: Question/comment - With respect to Protolib wxWidgets support, I have historically treated that as an extended feature as opposed to a base feature of the Protolib toolkit, usually reserving its inclusion to when it is needed. With the 'waf' build, it is only brought in when 'enable-wx' is set. This was brought to my attention where cmake is detecting that I have wxWidgets on my system in the /opt/local path where it is installed (via MacPorts on MacOSX), but the compile fails because it doesn't seem to set the needed "opt/local/ ... " INCLUDE path to find the wxWidgets header files. My Makefiles and waf script use the "wxconfig -cxxflags" command to add the needed paths to the build ... I presume cmake has a means to do something like this, too?
Making wx support optional is fairly easy. CMake let's you define variables, so you'd make something like WX_SUPPORT, set the default to False, but if you want it, you define it on the CMake command like (cmake -DWX_SUPPORT=True ..).
As for generating project files, you get this for free in CMake. The default generator on Unix-like systems in Makefiles, but you can specify a generator on the command line and get XCode or Visual Studio projects instead.
As for the include headers, I didn't run into this with my tests, but it should get picked up. Usually what a CMake find module does is located the headers and libs and sets them in variables. Then you tell the generated "make" targets to add those variables to the includes or libraries.
And to be clear, then you'd wrap the check for wx and the addition of headers/libs behind a conditional tied to the variable.
@bebopagogo updated to make it an option and aligned to , Could you try again?
Oh and normally I do something like
cmake -S . -B build
cmake --build build
@bebopagogo Updated the PR a bit and b00ga did quite some testing. Could you take a look?
In the mean time I'll start on NORM to see if protolib still integrates nicely.
I was able to change the CMakeLists.txt to:
if(LibXml2_FOUND) include_directories(${LIBXML2_INCLUDE_DIR}) list(APPEND PLATFORM_LIBS libxml2) list(APPEND PUBLIC_HEADER_FILES include/protoXml.h) list(APPEND COMMON_SOURCE_FILES ${COMMON}/protoXml.cpp) endif()
and that resolved the issue. I also made a couple of other fixes so Mac OSX builds. Finally, I changed the CMake TARGET so it builds "libprotokit.a" to be consistent with the other build methods (make and waf). This is an area I've mentally self-debated for a long time ... whether to call use libprotolib.a or libprotokit.a ... I have favored the latter since it's less redundant with the 'lib' prefix, is a little more distinctive (less likely to collide with something else), and conveys what the library contains to a little clearer extent ... But that begs the question why isn't the repository also named "protokit" instead of "protolib". The answer is because it was administratively easier to not rename the repo and I missed the boat on the opportunity when we migrated to GitHub