Well, we haven't generated such a package - in the longest time ;-POn Sat, 30 Mar 2013 11:41:16 -0700
Gregg Smith <firstname.lastname@example.org> wrote:
> On 3/30/2013 11:14 AM, Jeff Trawick wrote:
> > On Sat, Mar 30, 2013 at 2:10 PM, Gregg Smith <email@example.com
> > <mailto:firstname.lastname@example.org>> wrote:
> > On 3/30/2013 11:01 AM, Jeff Trawick wrote:
> > To state the obvious, I'm probably doing something stupid.
> > I am using Visual Studio 2010 + SP1 (to get around an
> > incremental linking bug).
> > I have a directory with:
> > apr-1.4.x as apr
> > apr-util-1.5.x as apr-util
> > apr-iconv-1.1.x as apr-iconv
> > Within apr-util I try
> > l>nmake -f Makefile.win PREFIX=c:\apr1x USEMAK=1 ARCH="Win32
> > Debug" buildall checkall
> > This fails with
> > cd ..\apr-iconv
> > "c:\Program Files (x86)\Microsoft Visual Studio
> > 10.0\VC\BIN\nmake.exe" -
> > nologo -f apriconv.mak CFG="apriconv - Win32 Debug"
> > RECURSE=0 NMAKE : fatal error U1052: file 'apriconv.mak' not found
> > Stop.
> > Sure enough, there is no apriconv.mak there.
> > Am I supposed to do something first to generate them,
> > before I can use the apr-util Makefile.win?
> > Unless you have VC6, use apr-iconv-1.2.1-win32-src-r2.zip or
> > steal the .mak/.dep files from it.
> > http://apr.apache.org/download.cgi
> > Thanks, I'll use that.
> > Is there a reason we shouldn't commit the build support to svn?
> > (Is there something unique about that build support that warrants
> > leaving it uncommitted?)
> Probably not and I see they're in APR-Iconv/trunk which looks like
> where the 1.2.1 tag came from. Why they're not included in tag I can
> only guess. However, we do not want them landing in the Unix tarballs
> as that's the way it's been for a long time. I believe Bill for the
> longest time has been generating these win32 source packages on the
Yes, they aught to land in the tarball, but I've seen nothing that
suggests that there are enough reviewers to get 3 votes for any
incremental apr-iconv release, and the upstream and current activity
are both long dead. I've personally been using the last LGPL licensed
version of iconv (1.11) for a very long time. My own desire would be
to have some icu or other basis for handling xlate, but MS has never
seen any use to streaming codepage conversion, so there are no usable
native implementations in the base OS.
IIRC Mladen had worked on some interesting alternatives but I don't
recall where those stand.