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