apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Next steps for apr-iconv 1.2.0
Date Mon, 10 Oct 2005 02:08:24 GMT
Just a few observations, that someone else more familiar with the
autoconf magic might accomplish more quickly than I could...

* The installed library is still libapriconv.so - that's not right,
   it needs to be libapriconv-1.so.  (On win32, this is already
   libapriconv-1.dll).  That's why I suggest the next tarball will
   be 1.2.0 - it's a pretty major change, but truly only a correction
   of earlier invalid behavior.

* The make install does not appear to drop the include/* files into
   the install target tree.  Although it's in theory a private library
   for apr-util to consume, apr-util can't resolve the path to the
   apr-iconv source tree, only it's installed tree.

I don't mind continuing to support the unix build; but suspect someone
else can do in 10 minutes what it would take me an hour to dig through.

With those changes finished... apr-util needs some fixes

* --with-apr-iconv= doesn't correctly disable native iconv detection.

* the iconv linkage should be part of the resulting apu link flags.

And finally, although it's an httpd question (and an apr question if we
feel like shipping an apr-bundle-2.x.x package) the httpd project should
simply include apr-iconv in the source distribution bundle.  This would
mean that users of any visual studio 6 or later could build from the
source tarball, if they simply invoke srclib\apr\build\lineends.pl first.

Bill

Mime
View raw message