[reSIProcate] Questions about resiprocate roadmap

[Scott Godin]

I'm not aware of any plans.  You could submit a pull request for this if
you are willing to take on the work.  Would anyone be concerned over
accepting a pull request with these changes it in?  It will break older
compilers.

I don't have any issues myself.

Scott

On Sun, Apr 7, 2019 at 7:53 AM Karlsson <boost.regex at gmail.com> wrote:

> Hi all, does there has any plan to remove the resip::SharedPtr,
> std::auto_ptr and use the std::shared_ptr, std::unique_ptr ? We are got a
> lot of warnings with auto_ptr when compile with GCC, and it's seems the
> auto_ptr will no longer supported in the future GCC release.
>
> Thanks
>
> On Wed, Mar 7, 2018 at 4:26 AM Gregor Jasny via resiprocate-devel <
> resiprocate-devel at resiprocate.org> wrote:
>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Gregor Jasny <gjasny at googlemail.com>
>> To: resiprocate-devel at resiprocate.org
>> 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
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Gregor Jasny via resiprocate-devel <
>> resiprocate-devel at resiprocate.org>
>> To: resiprocate-devel at resiprocate.org
>> Cc:
>> Bcc:
>> Date: Tue, 6 Mar 2018 21:24:56 +0100
>> Subject: [reSIProcate] Questions about resiprocate roadmap
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
> _______________________________________________
> 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/20190409/4736d638/attachment.htm>