[GitHub] logging-log4cxx issue #3: LOGCXX-494: windows cmake build for log4cxx agains...

2018-04-02 Thread tschoening
Github user tschoening commented on the issue:

https://github.com/apache/logging-log4cxx/pull/3
  
> Any update on this? It's almost 3 months old now and no updates from the 
log4cxx team.

Because I responded on the mailing list:


http://mail-archives.apache.org/mod_mbox/logging-dev/201801.mbox/<1913119533.2018072120%40am-soft.de>

At least I don't have any plans to deal with such a major change in the 
build currently, I simply don't have the time to do so.

> Not recommending a change in the overall build system.

It's either about the addition of CMAKE to what is already there or the 
replacement of something which is already there, both are major changes from my 
understanding. And we already have Autotools, Maven, Shell Scripts, ANT and 
none of those is properly integrated with each other to support everything 
which is needed, like development iteration, version number updates, release 
date updates, site generation etc.

> The complete lack of windows build support at all in the project trunk is 
what worries me the most.

Build support in trunk was/is available using ANT and cpptasks and at least 
for some recent versions of Visual Studio this worked:

https://logging.apache.org/log4cxx/latest_stable/building/index.html

> The instructions on the web site tell people to go to a directory that 
does not exist and use a project file that is not there.

Because those instructions addressed a release.

> Version 0.10.0 eliminated all visual studio project files from the 
project[...]

I'm somewhat sure they have never been in trunk, but only in the release 
package and have been generated during the release process. If you look at the 
following packages, some generated projects are still available:

https://dist.apache.org/repos/dist/dev/logging/log4cxx/


---


[GitHub] logging-log4cxx issue #4: mbsrtowcs() returns the number of wide char,but no...

2018-03-21 Thread tschoening
Github user tschoening commented on the issue:

https://github.com/apache/logging-log4cxx/pull/4
  
I fixed this using "requested" like mentioned in LOGCXX-399 and the linked 
PR #4 on GitHub. Additionally I added a test "decodingtest" using 
"encodingtest" as template, but the problem didn't occur using my C++Builder 
because I lack the used API, so am not sure if that works at all. It didn't 
fail before and doesn't now, so in the worst case is simply not doing anything 
useful. ;-)


---


[GitHub] logging-log4cxx issue #4: mbsrtowcs() returns the number of wide char,but no...

2018-03-21 Thread tschoening
Github user tschoening commented on the issue:

https://github.com/apache/logging-log4cxx/pull/4
  
It's a string by definition so I guess we can ignore problems with 
terminating `0` within the string before `requested` has been reached.  
Additionally, `x * converted` should be wrong as well because how many bytes 
one multibyte character spans depends on the current locale, right? So sounds 
safe to assume in case of success that simply all requested characters/bytes 
have been processed. This is reported to work in the linked issues as well:

> Then I modified the "in.position(in.position() + converted);" to 
"in.position(in.position() + requested);"


https://issues.apache.org/jira/browse/LOGCXX-399?focusedCommentId=13969295=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13969295


---


[GitHub] logging-log4cxx issue #4: mbsrtowcs() returns the number of wide char,but no...

2018-03-21 Thread tschoening
Github user tschoening commented on the issue:

https://github.com/apache/logging-log4cxx/pull/4
  
This has been reported before with different possible solutions. Is 
"requested" really correct compared to e.g. `sizeof(...) * converted` or such? 
Less than `requested` chars could have been processed in theory even without 
any error.

https://issues.apache.org/jira/browse/LOGCXX-369
https://issues.apache.org/jira/browse/LOGCXX-399


---


[GitHub] logging-log4cxx issue #2: Build with autotools+maven

2018-03-06 Thread tschoening
Github user tschoening commented on the issue:

https://github.com/apache/logging-log4cxx/pull/2
  
There have been multiple discussions regarding CMake in the past, please 
search for them yourself on the mailing lists or in JIRA:

https://markmail.org/search/?q=list%3Aorg.apache.logging.dev+cmake
https://markmail.org/search/?q=list%3Aorg.apache.logging.log4cxx-dev+cmake

https://logging.apache.org/log4cxx/latest_stable/mail-lists.html


https://issues.apache.org/jira/browse/LOGCXX-486?jql=project%20%3D%20LOGCXX%20AND%20text%20~%20cmake


---


[GitHub] logging-log4cxx issue #3: windows cmake build for log4cxx against apr-2

2018-01-11 Thread tschoening
Github user tschoening commented on the issue:

https://github.com/apache/logging-log4cxx/pull/3
  
Just some notes: While it has been discussed in the past to move to CMAKE 
already, keep in mind that the current build bases on Autotools and/or Maven 
and/or Ant deals with things like projetc files generation, website generation, 
development iteration incl. version numbers etc. as well. So it's not only 
about adding CMAKE support, but one needs to ultimately decide which parts of 
the current build tools are kept and all that.


---