[reSIProcate] dumping autotools and moving to CMake?

[Francis Joanis]

Hi guys,

I've used CMake in the past to support Unix + Windows (nmake and Visual Studio) builds of a few projects.

I like CMake and the fact that a _single_ set of "make files" are used to generate the build scripts for the various platforms. This makes a few things like adding a new file to a project easier. We could also leverage CTest to run the unit/automated tests.

CMake is very powerful and can probably handle all the needs for the project. I haven't been involved much with resip lately, but I think CMake would be a good fit since resip is being actively used and maintained on both Unix and Windows.

We could use mingw/Cygwin/... with autotools for Windows but I think native MS builds will still be a requirement for some/most Windows users.

I'm available to help with the CMake port if we want to see how it goes. Has a sandbox branch been created yet?

Thanks and happy new year,
Francis

> On Jan 4, 2014, at 10:31 PM, Byron Campen <docfaraday at gmail.com> wrote:
> 
> Yes, any change like this would be an inconvenience to some. I hope that we could get an idea of how many would have a difficult time with a change like this, so if anyone falls into this category, please speak up. We are very much in a phase where we need this input.
> 
> Best regards,
> Byron Campen
> 
>> On Jan 4, 2014 5:47 PM, "Joegen Baclor" <jbaclor at ezuce.com> wrote:
>>> On 01/05/2014 12:24 AM, Daniel Pocock wrote:
>>> 
>>>> On 04/01/14 17:18, Byron Campen wrote:
>>>>       While I do like cmake, it is not a panacea, and there are some sharp
>>>> edges. I think it might be illustrative to try writing a cmake build for
>>>> rutil/stack (plus tests), and see how much pain we run into. I can give
>>>> this a go, since I have some experience with it.
>>> 
>>> Any feedback about it would be great, feel free to add to the wiki as well
>>> 
>>> In terms of priorities, I think that any cmake effort can probably wait
>>> until after the 1.9.0 release has been tagged though.  Most of my own
>>> tweaks are now committed and will appear in a beta9 tarball very soon
>>> and it would be useful to have any final concerns/problems listed if
>>> anybody thinks it is not suitable for release.
>> It is worth mentioning that some projects (like mine) has integrated resiprocate as a native submodule utilizing the capability of autotools to nest other project within a single homogeneous build. This is not a complaint but just a side note.  Whatever works best for resiprocate, I won't have trouble with.
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140105/214d884e/attachment.htm>