On Sat, 30 Mar 2013 11:41:16 -0700 Gregg Smith <g...@gknw.net> wrote:
> On 3/30/2013 11:14 AM, Jeff Trawick wrote: > > On Sat, Mar 30, 2013 at 2:10 PM, Gregg Smith <g...@gknw.net > > <mailto:g...@gknw.net>> 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 > side. Well, we haven't generated such a package - in the longest time ;-P 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.
