On Feb 16, 2005, at 12:01 PM, Aaron Walker wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Curt Arnold wrote:

The autoconf-based build is broken for Debian and BSD systems. There
has been discussions on the list but nobody has stepped up to volunteer
to revamp it and I'm a novice with regard to it. I've logged a bug
(http://issues.apache.org/jira/browse/LOGCXX-43) on this and added this
as a blocker for the 0.9.8 release. It will have to be done before an
0.9.8 release, but if I'm not going to take it on until I've run out of
other tasks that need attention and then I would likely beg one another
group for help.

What exactly needs fixing for Debian/BSD systems? I'd be more than glad to
provide a patch if I can figure out exactly what's broken.

I think the major problem is that it requires a later version of autoconf than is installed by default on most Debian or FreeBSD systems. The configure scripts could likely be radically simplified since the migration to Apache Portable Runtime since log4cxx no longer needs to know, for example, if pthread is available or not since that is hidden by the use of APR. The only things that I think would be useful to detect for log4cxx are whether mbsnrtowcs and wcsnrtombs are available, detecting an integer type that is the same size as a pointer and whether std::wcout and std::wcerr are available.


There is also no longer any need to be prefixed with LOG4CXX_ since the config file are no longer included in any of the log4cxx header files but only used in the implementation. I think their is support for --with-apr but maybe not --with-apu. I don't think the check target builds and runs the unit tests.


On BSD, the biggest cause of pains is the fact that you guys don't distribute
the tarball with configure, etc already generated like most packages. Just
doing this would solve a lot of headaches for folks that haven't messed with it
before on BSD. IIRC, the only other thing that's broken on BSD is the missing
HAVE_ALLOCA_H check in tchars.h, but like you said you're ditching that.

Would you recommend generating the configure from autoconf and including it in the distribution or skipping autoconf completely?





The only other thing I know of off the top of my head that needs fixing
configure-wise, is a few checks that don't work as they should. The one I know
for sure is the unicode check. While --enable-unicode works as it should,
- --disable-unicode does not.



0.9.7 was designed to support either the default multibyte encoding or wide chars. The current CVS HEAD can support both simultaneously. The code has been designed so that either wchar_t or UTF-8 encoding could be used as the internal character representation, however only the support code for wchar_t has been implemented. So instead of --enable-unicode, the switch should be somethink like --use-encoding=[wchar_t utf-8] or --use-utf8=[false true]





Reply via email to