Re: [reSIProcate] Preliminary CMake support (b-cmake-experiment)
On 20/01/14 05:23, Francis Joanis wrote:
> Hi,
>
> I'd like to let you know that I've committed some CMake work to the
> b-cmake-experiment branch (thanks to Byron who created it). I've also
> updated a bit the http://www.resiprocate.org/CMake_Evaluation wiki
> page but it will need more work.
>
> I've successfully tested CMake for rutil, resip, dum, reflow and
> reTurn on Debian (with SSL) and on Mac OS (without SSL). I'll try to
> give it a shot on Windows tomorrow if I get some cycles. The unit
> tests compile but they don't all pass / run well.
>
> Among other questions, I wanted to get your opinion on the usage of
> the contrib folder. I assumed that, generally speaking, we would
> prefer looking for dependencies at the OS level and not under the
> contrib folder.
>
> Should we have the build system actively look into contrib when
> searching for dependencies?
No - it should be a last resort. It is there for the convenience of
Windows users and we will continue to support it. However, on Linux
distributions, the libraries are maintained centrally and this generally
works quite well.
> The only exception I've allowed so far is for cajun, the JSON parser,
> since I couldn't find any Debian package for it. Also, this works well
> because cajun doesn't seem to include any cpp file (it doesn't need to
> be compiled on its own).
The source package is called cajun in Debian and Ubuntu
It is cajun-jsonapi in Fedora and soon EPEL
However, the "binary" artifact on Debian (the installable package) is
named libcajun-dev to follow Debian naming conventions:
http://packages.debian.org/search?keywords=cajun
Having cajun on all major platforms is part of the 1.9 release strategy
and it is just about done:
https://admin.fedoraproject.org/pkgdb/acls/name/cajun-jsonapi
> Also, if you have some time, I would appreciate if you could give it a
> shot and give your comments :) There are some instructions at the top
> of the wiki page.
>
> All and all the work wasn't too bad so far. Besides fiddling with the
> CMakeLists.txt files for each project I also had to create a few
> helper scripts that can be used by the CMake FIND_PACKAGE function.
> Those are located under build/cmake_modules.
The flame test is yet to come: making sure it can cross compile for
Android and whatever else
I'm guessing CMake goes some of the way towards doing that but we will
still need to review the wrapped scripts I developed for build automation
We also need to understand how everybody else feels about the potential
CMake move