[log4cxx] Release Prep

Before I go and do a release of log4cxx, are there any issues that may need to be taken care of before the next release? Otherwise, if there are no objections, I'll call for a release vote here shortly for version 0.12.0. -Robert Middleton

Re: [log4cxx] Release Prep

Guten Tag Robert Middleton, am Dienstag, 13. April 2021 um 04:09 schrieben Sie: > Before I go and do a release of log4cxx, are there any issues that may > need to be taken care of before the next release?[...] Including the latest PR makes sense, the more docs the better. :-) https://github.com/

Re: [log4cxx] Release Prep

Hi Robert, Using ${CMAKE_SOURCE_DIR} instead of a relative path creates a problem when including the log4cxx root directory from a higher level CMakeLists.txt. CMAKE_SOURCE_DIR is (inconveniently) set where the top-most CMakeLists.txt file resides. You are using ${CMAKE_SOURCE_DIR} in src/main

Re: [log4cxx] Release Prep

> Using ${CMAKE_SOURCE_DIR} instead of a relative path creates a problem > when including the log4cxx root directory from a higher level > CMakeLists.txt. CMAKE_SOURCE_DIR is (inconveniently) set where the top-most > CMakeLists.txt file resides. > > You are using ${CMAKE_SOURCE_DIR} in src/main

Re: [log4cxx] Release Prep

Also, question for Thorsten: are you comfortable closing PR #22 at this point? There's been no activity on it for a year at this point, and it seems like the resolution we came up with was "don't do anything". -Robert Middleton On Wed, Apr 14, 2021 at 9:27 PM Robert Middleton wrote: > > > Using

Re: [log4cxx] Release Prep

> Or maybe we just need something like LOG4CXX_SOURCE_DIR? yes, I like that idea - something we control. Virus-free. www.avast.com

Re: [log4cxx] Release Prep

If you're able to test the PR that I just did, that would be helpful: https://github.com/apache/logging-log4cxx/pull/63 All of the tests pass so it's probably good, but an extra set of eyes is helpful. -Robert Middleton On Thu, Apr 15, 2021 at 4:32 AM Stephen Webb wrote: > > > Or maybe we just

Re: [log4cxx] Release Prep

Guten Tag Robert Middleton, am Samstag, 17. April 2021 um 02:09 schrieben Sie: > If you're able to test the PR that I just did, that would be helpful: > https://github.com/apache/logging-log4cxx/pull/63 Stephen, you can't be chosen for review in GitHub, the dialog simply doesnm't find you, even t

Re: [log4cxx] Release Prep

Hi Robert, I suggest adding the following to 'change-report-gh.md' Migrating from 0.11.0 - Code changes are required for log4cxx pointer downcasting. The automatic cast performed by the log4cxx 0.11 smart pointer assign operator is no longer supported. For example:

Re: [log4cxx] Release Prep

Yes, adding a note about casting would be a good idea. Note that there is a log4cxx::cast function that should handle this for you - I believe that this is more reliable than using dynamic_cast, especially across DLL boundaries. It should also properly do the shared_ptr portion(so that you can ha

Re: [log4cxx] Release Prep

Yes, your fancy new cast function looks like a better approach. Should the note mention it uses the aliasing constructor std::shared_ptr or is it always going to be safe with log4cxx::Object pointers? On Thu, Apr 22, 2021 at 7:54 AM Robert Middleton wrote: > Yes, adding a note about casting wou

Re: [log4cxx] Release Prep

As long as the classes that you are trying to cast to/from descend from log4cxx::Object, the cast should work fine. The aliasing constructor for std::shared_ptr means that both shared_ptrs point at the same control block for the shared pointer, so the object is the same; I'll add some notes about