Results on 1.2.8/0.9.13, roll apr-iconv?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Thanks everyone for their critical eyes and testing on 1.2.8/0.9.13, the
results for the releases were unanimous, and I add my own +1 to all of
the packages.

Unfortunately, the initial .mak/.dep file creations for win32 were wrong for
apr-util v 0.9.13 package, and the -win32-src.zip packages for apr-iconv were
also created incorrectly by me with hardcode local paths.  Since this is a
trivial post-release packaging snafu, I've simply re-extracted the .mak+.dep
files and replaced the affected .zip's in /dist/apr/ for windows source users.

The apr-iconv issues go a bit deeper though - there is alot of warning noise
building apr-iconv on VC2005.  It seems time to refresh those packages so that
users of the modern compiler can use it without incident.

I'd like to plan to go ahead a roll apr-iconv packages by early next week.
In the case of 0.9.13 this includes the fixes for windows compilation, and
a small fix to the ucs2 byte order mark (it was added to streams only on
continuation of stream, it should have only been added on start-of-stream).

The same fixes apply to 1.2.0 - but here is where I could use a hand (knowing
how crazy my schedule's been).  We didn't correctly tag the resulting .so for
unix as libapriconv-1.so (missing -1) in earlier versions.  It's NOT binary
compatible with libapriconv[-0].so and this is a bad thing.  Fixing it results
in a behavioral/expectation change, thus moving 1.1 -> 1.2.

I realize next-to-nobody is trying to build apr-iconv-1 on unix, and even
for windows by 2.0 I'd like it to be gone in favor of citrus.  But that said,
it's still out there, and we may as well lug it along for one last technically
correct release before archiving the effort.  Any volunteer to help on the
unix build side?

Bill

Re: Results on 1.2.8/0.9.13, roll apr-iconv?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Kean Johnston wrote:
>> I realize next-to-nobody is trying to build apr-iconv-1 on unix, and even
> I am :) And I just ran into the issue where apu-1-config refers to the
> internal source directory for apr-iconv, and the fact that the headers
> for apr-iconv don't get installed.

Apparently, although apr-iconv is meant to be PRIVATE (accessed through
apr-util/xlate API) - we are unable to build apr-util itself, bleh.

It seems the public headers aught to be installed in the apr/apr-util
public directory, so apr-util can reliably build against it.

>> for windows by 2.0 I'd like it to be gone in favor of citrus.  But
>> that said,
>> it's still out there, and we may as well lug it along for one last
>> technically
>> correct release before archiving the effort.  Any volunteer to help on
>> the
>> unix build side?
> Yes, I do. Tell me what you need / want.

Patches are welcome!  Chatter (not official records/decisions) is welcome
on the irc.freenode.net #apr channel to help untangle what is done where,
and why, and how to work around quirks.

Re: Results on 1.2.8/0.9.13, roll apr-iconv?

[Kean Johnston <ke...@armory.com>]

> I realize next-to-nobody is trying to build apr-iconv-1 on unix, and even
I am :) And I just ran into the issue where apu-1-config refers to the
internal source directory for apr-iconv, and the fact that the headers
for apr-iconv don't get installed.

> for windows by 2.0 I'd like it to be gone in favor of citrus.  But that said,
> it's still out there, and we may as well lug it along for one last technically
> correct release before archiving the effort.  Any volunteer to help on the
> unix build side?
Yes, I do. Tell me what you need / want.

Kean
-- 
Deckard: "I don't work here anymore. Give it to Holden. He's good."
Bryant : "I did. He can breathe okay as long as nobody unplugs him."
       --- Bladerunner

Re: Results on 1.2.8/0.9.13, roll apr-iconv?

[Mladen Turk <mt...@apache.org>]

William A. Rowe, Jr. wrote:
> 
> The apr-iconv issues go a bit deeper though - there is alot of warning noise
> building apr-iconv on VC2005.  It seems time to refresh those packages so that
> users of the modern compiler can use it without incident.
>

There are also few warnings (like dozen) of them when compiling
APR on Win64 platform. Luckily nothing major.
I'll clean up that a bit next week.

Regards,
Mladen.