What about the offering[1] from Pierre (MS guy) to write a script that
generates the mak files? Just in case you don't want to do it yourself ;)
Why not taking advantage of that?

Greetz
Mario

[1] http://www.mail-archive.com/dev@httpd.apache.org/msg56189.html

On 2 April 2013 06:25, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:

> 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.
>

Reply via email to