Hi Brad, This seems to run pretty well -- as you say, it's vastly faster than the ./configure variant!
My main concern would be that having 2 parallel build systems adds a bit more friction to the development process (e.g. anyone adding a new source code file needs to remember to update/test both), and we don't necessarily have any folk knowledgeable about CMake. However, given that c-ares is pretty stable, that might not be a big issue, particularly if we document that the autotools variant is the "official" build system. One thing to help would be to set up automatic builds -- if we set up Travis / AppVeyor build variants for CMake, we should be able to quickly spot any omissions. Obviously, including the tests in the CMake setup would ideally be needed, and there's a few other things that might need tweaking: - Your patch requires CMake 3.0, which is later than is installed at Travis (which has 2.8.7 I think). Do you need 3.x features, or could you set a lower minimum version? - The CMake build seems to assume use of the main source code directory, but I've seen other CMake builds that allow parallel build subdirectories. If the latter is possible, it might allow an autoconf build and a CMake build to use a shared source tree, reducing the size of the Travis build matrix. - For tidiness it would be nice to update .gitignore to list any CMake build detritus. A couple of other questions (from a CMake n00b): - Where does SOVERSION of 3.0.1 come from? - Is there any way to automatically get VERSION 1.11.0 from ares_version.h so there's fewer things to manually sync? Thanks, David On Tue, Jun 28, 2016 at 1:00 AM, Brad House via c-ares <c-ares@cool.haxx.se> wrote: > I have attached a patch which adds cmake build system support to C-Ares. > The patch does not modify any source files, it only adds 3 new files > (CMakelists.txt, ares_build.h.cmake, ares_config.h.cmake) which form the > build system. I've tried to go through as much of the autotools tests and > extracted what I thought was appropriate, though many of the tests aren't > as in-depth in CMake as they are for autotools ... it is unclear why some > of them exist at all, I'm guessing for legacy systems that CMake probably > doesn't support anyhow. > > Building the library, and examples (adig, ahost, acountry) plus installation > should work. The tests have not yet been integrated. I'm hoping this can > be improved on by others for platforms I do not have access to. > > My motivation for doing this is I maintain some projects that use c-ares > and chain build it as part of the build rather than referencing it as an > external library. The autotools project didn't integrate very well with > cmake, and quite frankly, it took longer for configure to finish (due to > argument detection of recv, recvfrom, and send -- which I've eliminated > in cmake with some "educated guesses" that seem to work well) than for all > of CMake and the entire build process to run for the projects. > > The CMake build system for C-Ares has been tested on the below platforms > without issue: > * Windows x86/x64 MinGW-w64/MSYS2 > * Windows x86/x64 Visual Studio 2005 > * Linux x86/x64 (CentOS 5, Ubuntu 14.04 [GCC, Clang]) > * FreeBSD 9 x86 (GCC) > * FreeBSD 10 x64 (clang) > * Solaris 10 x64 (GCC) > * Solaris 10 Sparc 32/64 (GCC) > * AIX 5.3 POWER 32/64 (GCC) > * MacOSX 10.11 (clang) > > Please let me know if there are any questions/comments/concerns. > > Thanks! > -Brad