Re: Compiling on NetBSD and MSYS

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]