Curt Arnold wrote: > > > On Oct 23, 2006, at 12:23 PM, Jing Zheng wrote: > >> >> I know from some previous posts that a release requires a vote >> process and it >> could take long. But getting sources from svn head and build >> doesn't look >> attractive at all. Trying to check out code and build could get into a >> situation I have today: the code is not compilable. I have seen watch >> log4cxx since 2004. I tried to use log4cxx at that time and found >> 0.9.7 is >> said to be very buggy and 0.9.8 is on the way, so I dropped log4cxx >> and used >> some proprietary logging software. Recently I want to try log4cxx >> again and >> found 0.9.8 is not released and 0.10.0 is on the way. > > Same version, just a change in the number since 0.9.8 would have > implied binary compatibility with 0.9.7. > >> This is not meant to >> complain, I understand that log4cxx is an open source project, >> people are >> contributing their own time for free. But if there is no usable >> release, >> potential users will go away and contributers' time to this project >> would be >> largely wasted, cause the project is not used by anyone in the past >> 2 years. > > It is not like it hasn't been used, but I would agree that a formal > release would make things better. > >> I know another group in my firm choose log4cpp instead. log4cpp is >> not as >> feature rich as log4cxx, but it can be built easily. people with basic >> logging need(I think a lot of users fall in this category) can use >> it with >> ease. >> >> sorry if this offends anyone, that is not my intention. I come from >> log4j, I >> really like to see log4cxx's user base grow and become the first >> choice when >> people come to c++ logging. > > Definitely getting a release out the door is the immediate goal and > there is no other log4cxx development issue before it. If you have > any interest in contributing to the release, check out the project > JIRA. https://issues.apache.org/jira/browse/LOGCXX-62 is the bug > report for the 0.10.0 release and identifies the issues that are > blocking the release. However, going though and reviewing other > issues and creating patches for other issues will make the release > push easier when time is available for a release death march. > > >> >> A few ideas for building log4cxx in a self-contained manner: >> 1. it would be nice to have build dependencies like cpptasks.jar and >> ant-contrib.jar shipped with the build or automatically downloaded >> from the >> web > > My thoughts were that the release archive would have the autotools > and the project files for the various versions of Visual Studio and > other IDE's that were generated from the Ant build. I'll think some > on it > >> 2. provide option to link apr statically, I notice ant build has >> such an >> option. subversion, as of 1.4, requires apr 0.9x. >> > > Linking apr and apr-util statically is the default with the ant > build. Are you saying you'd like that option with the autotools > build, or do you have an issue or suggestion regarding the ant > build? I'd recommend building statically since I'm not sure that > the APR termination is handled well if the calling app and log4cxx > both share the same shared instance of APR. > > > > sorry to be unclear about the static linking one. I was trying to say I like static linking with apr. ant build with log4cxx does have the option, but the configure script doesn't. If configure script is shipped with the release, it would be nice it also has static link option, a lot of c/c++ people are more comfortable/family with gnu family.
subversion requires apr 0.9.x and log4cxx requires 1.2.x. although apr 1.2.x has .so in the form of "apr-1...so" to distinguish itself from older version, having 2 different version of a same library under the same directory is not a good idea. What I meant self-contain is that log4cxx has everything it needs to build, including 3rd party software. If it requires linking with 3rd party library, static linking would be preferred as default build option, then the users won't get surprise from your library when they update some 3rd party library for some other purposes. It is a pain that you have to download library x,y,z and build them individually when you just want to use library a. I would like to see log4cxx has everything in one tar.gz file to build. the .gz file will be larger, but the users will definitely have an easier and enjoyable build process. -- View this message in context: http://www.nabble.com/when-where-can-we-get-a-usable-log4cxx-release-tf2495572.html#a6961969 Sent from the Log4cxx - Users mailing list archive at Nabble.com.
