Subject: Re: [PATCH] Cmake-ify c-ares -- v2

Re: [PATCH] Cmake-ify c-ares -- v2

From: Brad House via c-ares <c-ares_at_cool.haxx.se>
Date: Tue, 27 Sep 2016 07:44:32 -0400

I've attached v2 of my CMake patch for c-ares. The changes are:
  * Sync with master (no configure-time type size checks)
  * Support iOS multi-arch building
  * Require only CMake v2.8

The main thing that still needs to be done is to build the tests,
however I'm not seeing how to do that with CMake 2.8 as was requested
since it doesn't have C++11 support (needed to set the right flags
during compilation). Even with later CMake versions, I'm not exactly
sure how to detect a C++11 compiler ... so it will take quite a bit of
research. (It doesn't help that I'm a C guy and try not to touch C++).

That said, I don't know if that is a show-stopper for an experimental
build system distributed in parallel with the primary autotools build
system.

-Brad

On 6/28/16 8:42 AM, Brad House wrote:
> I've just confirmed CMake 2.8 (tested 2.8.12.2 on Ubuntu 14.04) works fine,
> it doesn't appear I'm depending on any v3 features, so it is safe to reduce
> the minimum version.
>
> -Brad
>
>
> On 6/28/16 7:56 AM, Brad House via c-ares wrote:
>> Commenting below ...
>>
>> On 6/28/16 6:42 AM, David Drysdale via c-ares wrote:
>>> 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.
>>
>>
>> I agree, I couldn't figure out any way to make use of the Makefile.inc
>> which lists the source files, which would have been convenient. Since
>> C-Ares releases only happen once every couple of years, I can definitely
>> make sure I do any regression testing across the platforms I have access
>> to prior to release to look for anything that might have broken.
>>
>> Technically there is another build system too, the Windows "NMake" files,
>> but autotools and windows nmake are able to share the Makefile.inc for
>> the list of sources.
>>
>>
>>> 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:
>>
>>
>> Hooking into Travis sounds like a good idea. I need to wrap my head
>> around the test system to figure out how to integrate that still.
>>
>>
>>> - 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?
>>
>>
>> I'll need to test to see if there was really any reason to require
>> CMake v3 or not. I know we found a reason in some other projects, but
>> I think it was behavior of FindPackage(OpenSSL) that was broken until
>> v3... obviously not relevant here.
>>
>>
>>> - 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.
>>
>>
>> Actually, that's not true. I never build using cmake in the main source
>> tree. I typically do something like:
>>
>> cd c-ares
>> mkdir build
>> cd build
>> cmake -DCMAKE_BUILD_TYPE=DEBUG -DCARES_STATIC=ON -DCARES_STATIC_PIC=ON ..
>> make
>>
>> ...
>>
>> However, I haven't seen what would happen if the autoconf version ran
>> in the source tree and CMake ran outside. I can't guarantee it would
>> reference the right ares_config.h/ares_build.h files. It *should* since
>> it sets the include path of the build directory first.
>>
>>
>>> - For tidiness it would be nice to update .gitignore to list any
>>> CMake build detritus.
>>
>>
>> We could, but I typically wouldn't recommend building in the source
>> directory anyhow Its not like autoconf that has to run ./buildconf
>> to generate a bunch of files before ./configure can run so I'm not
>> sure if it makes sense to add any exclusions.
>>
>>
>>>
>>> A couple of other questions (from a CMake n00b):
>>> - Where does SOVERSION of 3.0.1 come from?
>>
>>
>> I extracted that from the autotools Makefile.am:
>> CARES_VERSION_INFO = -version-info 3:0:1
>>
>> I'm pretty sure these are equivalent.
>>
>>
>>> - Is there any way to automatically get VERSION 1.11.0 from
>>> ares_version.h so there's fewer things to manually sync?
>>
>>
>> I think the actual C-Ares VERSION can probably be removed completely from the
>> line you are referring to. I don't believe it is actually being used for anything,
>> the SOVERSION is the important one.
>>
>> I don't think we can easily extract VERSION from ares_version.h because we don't
>> have access to a posix shell like we could assume with autotools. We might be able to
>> build an executable just for that using the ares_version.h, but I'm not sure
>> how that might impact cross-building (I'm not familiar with creation of helpers
>> in a different platform than the target with CMake).
>>
>>
>> -Brad

Received on 2016-09-27