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-06-28