< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] dumping autotools and moving to CMake?


    Well now hold on;

1) autotools is not going anywhere, yet
2) While we maintainers have an interest in making the maintenance work easier (eg; not having to maintain two build systems), it is also really important to minimize the hurdles downstream needs to deal with (not just because we're nice people, but also because we want our stuff to be used by people who one day might be roped into^w^winterested in helping us maintain stuff).

Best regards,
Byron Campen

On 1/5/14 12:00 PM, Douglas Hubler wrote:

I was disappointed to see auto tools going because I understand that and not cmake but I'm not very involved so I don't really count

On Jan 4, 2014 10:31 PM, "Byron Campen" <docfaraday@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel