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_at_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
Received on 2016-06-28