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

Re: [reSIProcate] Questions about resiprocate roadmap


I'm agree replace the currently resip::SharedPtr by std::shared_ptr, and remove the auto_ptr to support C++ 11 and 17.

And suggest make resiprocate works with c-ares officially code base.

Thanks

On Wed, Mar 7, 2018 at 4:24 AM, Gregor Jasny via resiprocate-devel <resiprocate-devel@xxxxxxxxxxxxxxx> wrote:
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel


---------- Forwarded message ----------
From: Gregor Jasny <gjasny@xxxxxxxxxxxxxx>
To: resiprocate-devel@xxxxxxxxxxxxxxx
Cc: 
Bcc: 
Date: Tue, 6 Mar 2018 21:24:56 +0100
Subject: Questions about resiprocate roadmap
Hello,

I'd like to share some thoughts and ask some questions about the future
roadmap of resiprocate.

* Schedule for stable 1.11 release *

It's been a long time since the last resiprocate stable release. The
first 1.11 alpha was tagged in November 2016, the first beta in January
2017. Debian seems to have picked up those betas and ships them in the
stable distribution release.

Since the last beta a lot of bug fixes went into master. Also
resiprocate is now compatible with OpenSSL 1.1 which is crucial for most
Linux distributions because they try to phase out OpenSSL 1.0

Do you see any blockers preventing a 1.11 release or do you have patches
that should definitely be part of an upcoming stable release? What's the
release process for a new stable resiprocate?

* Switch to C++11 *

At $Company we use resiprocate in a C++11 (and soon C++14 code base).
Resiprocate's use of auto_ptr also on external interfaces gives us some
deprecation warnings for auto_ptr. Surerely we could silence those, but
AFAIR the final C++17 standard removed auto_ptr completely. So users of
resiprocate will have to enable special C++ standard library
compatibility flags, soon.

What do you think about moving to C++11 after the 1.11 release has been
branched off?

* Google Test as a test driver *

In several projects I used Google Test (and Mock) as a testing
framework. If you don't abuse it it results in elegant and nicely
readable tests. Also any detected errors are pretty descriptive and help
the developer to figure out what's going on.

Google Test supports fusing all own internal source files into one
single file so embedding into a project isn't too intrusive. I prepared
a test branch with a single converted test here:

https://github.com/gjasny/resiprocate/tree/add-google-mock

Google Test supports grouping of test cases into test suites and
theoretically we could create a single unit test binary per library.

* clang-format rules file *

Regardless of how hard I try, there are always some formatting errors in
my pull requests.  How about creating a clang-format file with the
preferred formatting and add it to the repo? One could the use 'git
clang-format' (or standalone clang-format) to format any patches to the
desired style.

* CMake buildsystem

My workstation OS is right now MacOS so there is no up-to-date
buildsystem with IDE support within the resiprocate repository. In the
past there was an initiative by Francis Joanis and Byron Campen to add
the CMake buildsystem. I picked up their work and adjusted it to the
current code base.  You can find a proof-of-concept that builds rutil,
resip, dum, reflow, and reTurn here:

https://github.com/resiprocate/resiprocate/pull/107

It works with CLion, Xcode and Ninja/Make on MacOS and Ubuntu 16.04.
I'll test (and probably fix) it on Windows later.  My general question
would be if there is interest in CMake at all and if you could imagine
to remove the Visual Studio solutions and projects in favour of CMake to
reduce maintenance cost. (Same question for autotools).


Thank you for your feedback!


Cheers,
Gregor