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
