[WIP] Add CMake buildsystem for rutil, resip, dum, reflow, reTurn

[gjasny]

Hello,

I revived and modernized the experimental CMake branch and made is compile on my Mac. More platforms will follow if time permits and there is actual interest.

[gjasny]

For the record, my CLion flags were:

-DCMAKE_CXX_COMPILER_LAUNCHER=ccache
-DCMAKE_C_COMPILER_LAUNCHER=ccache
-DWITH_SSL=ON
-DOPENSSL_ROOT_DIR=/usr/local/Cellar/openssl/1.0.2n
-DSRTP_LIBRARY=/usr/local/Cellar/srtp@1.6/1.6.0/lib/libsrtp.dylib
-DSRTP_INCLUDE_DIR=/usr/local/Cellar/srtp@1.6/1.6.0/include

[dpocock]

This will have a big impact on packaging for Debian and Fedora. It would be really important to test that before merging this change. In particular:

• do the packages build?
• do they pass automated checks (e.g. lintian)?

[Arezohayeman]

#107

[seanchann]

what progress with this?

[tangm421]

I have great expectations for this, how is the progress？

[sgodin]

Daniel Pocock posted a concern on March 7, 2018. I'm guessing no one has had cycles to progress this since then. Feel free to use the branch code if it helps your project.

[gjasny]

I think I have a 2019 branch at work.

[pengweichu]

Can this PR be merged into master?

[dpocock]

In the short term, there is a higher priority activity, resolving the Fedora RPM packaging. There are some very minor issues I need to fix, I've been in discussions about that.

The CMake change might be a temporary setback for the Fedora RPM packaging, from my perspective, it is better to do the final Fedora fixes, leave that version running in the Fedora world and then spend some time with CMake.

I have more urgent deadlines in January but I plan to look at the Fedora RPM issue in February. I would only be able to look at the CMake change after that.

In principle, I think it is important to consider CMake compared to autotools, especially for Windows support.

On the other hand, I know there are sometimes glitches with CMake builds, the tests sometimes fail on the wrong error, for example, it gives red herrings with errors about pthreads but in fact the real error is unrelated to pthreads. I had experiences like this working with Blender builds. Once everybody knows about these glitches it is OK but people can be distracted or surprised when something like this happens.

[dpocock]

Here are some further observations on the procedure for completing a change of build system from autotools to CMake

These steps are based on the idea that we make the autotools build complete so we can compare the autotools and CMake build results side-by-side

Build output

• in the Autotools build, check for any source files that are never built. If necessary, add them to the Autotools build.
• compare the file listing of output files (make install) from an Autotools build and a CMake build
• compare the content of output files (make install) from an Autotools build and a CMake build

Tarball contents (make dist)

• compare the Git repository file list to the Autotools make dist tarball file list. If something is missing from the tarball, fix it first in Autotools config
• compare the Autotools make dist file list with the CMake make dist file list
• do the same comparisons for content of auto-generated files

[dpocock]

The tests in my comment above could be automated with a script. I'll write the script for that.

[dpocock]

The more recent CMake-based Android tools provide a way to build dependencies like reSIProcate.

Apparently Google includes CMake versions 3.6 and 3.10 in the SDK / NDK and projects that build with one of these versions will be relatively easy to build with the NDK.

I suggest putting a comment about this in the top-level CMakeLists.txt so people are less likely to increase the CMake version in the short term.

https://developer.android.com/ndk/guides/cmake

[dpocock]

I've started looking at this more closely

Byron started a branch for cmake in the main repository, there are some commits in 2014. It looks like that branch was not forked for this new work. @gjasny did you start with a copy of the files from that branch or did you start fresh? I'm happy to spend time on a more detailed comparison of the branches to see if we need to cherry-pick anything from the 2014 effort into your branch. Here is the 2014 branch
https://github.com/resiprocate/resiprocate/tree/b-cmake-experiment

@gjasny I saw you also have two other branches with earlier attempts at this. It looks like you did not merge those into the branch in this pull request, is there anything in either of those branches that we may need to cherry-pick?
https://github.com/gjasny/resiprocate/tree/2017-cmake-experiment
https://github.com/gjasny/resiprocate/tree/2018-cmake-experiment-full

There is one branch in the main repository, it is newer than the branch in the pull request. Once again, it isn't a merge from the earlier pull requests but it looks like you may have copied files into the branch as the other contributors are mentioned in commit 838eec2
https://github.com/resiprocate/resiprocate/tree/2019-cmake-experiment

[dpocock]

I've done the following:

• create a new branch, b-dpocock-cmake derived from 2019-cmake-experiment
• merge the master branch into b-dpocock-cmake
• update CMakeLists.txt to remove SharedPtr

Some of the libraries build, I'll make a list of the pending things to fix before this can be merged back into master

[dpocock]

I've created a script to run both an Autotools build and a CMake build and compare the output
https://github.com/resiprocate/resiprocate/blob/master/build/autotools-cmake-comparison.sh

The script does a range of checks on each build, for example, checking for source files that are never compiled, building in the tree, running make install, make dist and doing a test build on the tarball.

When we get to the point where the differences between the two builds are negligible we can drop the Autotools build and migrate completely to CMake on the master branch.

[dpocock]

Some of the pending tasks to complete CMake support:

• look for code changes in the b-dpocock-cmake branch and cherry-pick them back to master if appropriate
• add CMake options corresponding to all the flags in configure.ac,
  • https://github.com/resiprocate/resiprocate/blob/master/configure.ac
  • see AC_ARG_WITH and AC_ARG_ENABLE
  • helpful command: egrep 'AC_ARG_' configure.ac
• add CMakeLists.txt to resip/recon and apps/* directories, make sure we build everything
• fix the CPack file list
• adapt build/debian.sh to call CMake
• adapt build/release-tarball.sh to call CMake
• review the output of the script mentioned above,
  • https://github.com/resiprocate/resiprocate/blob/master/build/autotools-cmake-comparison.sh
  • in particular, make sure that any recently added source files are listed in the CMake configuration
  • review the TO-DO list in the script

[dpocock]

Libraries in contrib/*

@gjasny do you need CMake to build any of those libraries for Xcode or you have another way to obtain the libraries?

@sgodin do we want to use CMake for libraries in contrib/* or do you want to keep the *.vcxproj files there?

For Linux users we would try to use libraries from the package repositories whenever possible

For Android we would try to build libraries in the ndkports repository here, we could copy them to there or we could get them as submodules:
https://github.com/resiprocate/ndkports

[dpocock]

@gjasny thanks for starting this work, it has now been merged to master