logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: [VOTE] log4cxx 0.10.0 release candidate
Date Wed, 27 Feb 2008 00:12:12 GMT

On Feb 26, 2008, at 5:42 PM, Stephen Bartnikowski wrote:

> Hi Curt,
> My usage for Log4cxx in the near term currently involves three  
> platforms,
> Mac OS X Server, FreeBSD, and SUSE (both open and enterprise). The  
> idea for
> my product is to refer my end-users to log4cxx for installation,  
> rather than
> including the lib and headers in my distribution. So I'll describe my
> experiences installing them using the latest build instructions.
> On Mac OS X Server, I noticed the instructions assume the user has  
> 10.5 /
> Leopard. I feel this assumption should be stated for the folks like  
> me who
> haven't upgraded from 10.4 / Tiger yet. Fortunately, I already know  
> how to
> build on Tiger, thanks to your help. It's my intent to simply take  
> Log4cxx
> and dump it into a Framework so the end-user of my product doesn't  
> have to
> deal with extra work or the so-called DLL-hell.

I've got some uncommitted changes that tries to clarify that a bit.   
You would prefer an Xcode project that assumes 10.4 and builds APR and  
APR-Util with instructions on how to switch it to use the APR and APR- 
Util provided with the 10.5 SDK?

> On both FreeBSD and SUSE, I started out giving the autotools  
> instructions a
> shot. But neither platforms have apt-get. Many platforms have  
> different
> package managers, so it seems deficient to use only one platform's  
> manager
> in the example. I would rather see a link to the apr and aprutil  
> project
> download pages.

I thought that command would give the intent (install APR and APR-Util  
using your package manager of choice) and that the user would be able  
to translate that to there distribution.  In earlier revs, I had "# or  
your platform's equivalent)" but that resulted in text that flowed  
outside the text box so I removed it.  The APR and APR-Util sites do  
not have a maintained description of installation on different  

> (autogen.sh being referred to as autoconf.sh has already been  
> mentioned.)
> On FreeBSD, autogen.sh doesn't get very far:
> libtoolize: not found
> aclocal: not found
> autoconf: not found
> automake: not found

Okay, so a RC should include the generated configure files and should  
be checked against FreeBSD.

> So I fell back to the ant build. The ant instructions no longer  
> mention the
> shared / static options for each of the libraries, but that's fine. By
> default, it builds the liblog4cxx.so just fine. I think this is  
> satisfactory
> for what I need.

I'll check and remedy that.

> If I have to distribute Log4cxx with my product, however, this isn't  
> so
> great. If I do the ant build for a liblog4cxx.so that sucks its  
> dependencies
> in staticly, then ant will complain and not complete. For example,
> specifying -Dapr.lib.type=static and -Dapr-util.lib.type=static will  
> result
> in an error message telling me they must both be the static, even  
> though
> that's what I asked for. But again, I can let this slide.
> I honestly really haven't given RC2 on SUSE a fair shot yet, but  
> having more
> generic instructions on how to get apr and aprutil would have helped.
> Finally, an install target would be immensely helpful...something  
> that would
> take the right headers and libs and dump them in the appropriate  
> platform
> location. But this is not a show-stopper.

If you could contribute one, that would be very helpful.  It isn't  
something that I could do without effort.

> Overall, I think the release could use some real nice-to-haves, but  
> I don't
> think there's anything I couldn't work around.
> - Stephen

View raw message