logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Bartnikowski" <sbartnikow...@barkinglizards.com>
Subject RE: [VOTE] log4cxx 0.10.0 release candidate
Date Fri, 29 Feb 2008 18:34:10 GMT
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org] 
> Sent: Tuesday, February 26, 2008 6:12 PM
> To: Log4CXX User
> Subject: Re: [VOTE] log4cxx 0.10.0 release candidate
> 
> 
> 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?


Maybe just some extra documentation on how to cook up 10.4 XCode project
files. Yeah, an Xcode project for 10.4 is helpful, but you can't please
everyone. It might not be worth the effort to go the extra mile in this
case.

 
> >
> > 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 platforms.


I'd be fine with just a second line or an otherwise reformatting of "# or
your platform's equivalent". That or a reference to the APR and APR-Util
project sites for downloading and installing. I'm just saying that a newish
guy to the unix/lunix field might not have heard of apt, or Debian for that
matter, and get confused.

Now, take that with a grain of salt, because I'm also a little biased
against the Unix and Linux package managers, especially after being on both
ends of them. In creating a package or installing one, I tend run into
errors more often then not. And half the time, the package isn't found and I
have to download it from the project page anyway.


> > (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.


That'd be great!


> > 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.


Cool.


> > 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.


Yup, I understand. Unfortunately, since I don't know Ant or autotools well,
the best thing I could turn out for you reliably would be a shell script
that copied the lib and headers to the appropriate install locations. And
that's not really ideal. I'll let you know if the time to figure that out
lands in my lap.


Thanks again Curt!

- Stephen


Mime
View raw message