You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2013/04/02 06:25:41 UTC
Re: using new apr-util command-line make files... stuck on
apr-iconv
On Sat, 30 Mar 2013 11:41:16 -0700
Gregg Smith <gl...@gknw.net> wrote:
> On 3/30/2013 11:14 AM, Jeff Trawick wrote:
> > On Sat, Mar 30, 2013 at 2:10 PM, Gregg Smith <gls@gknw.net
> > <ma...@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.
Re: using new apr-util command-line make files... stuck on apr-iconv
Posted by Ben Reser <be...@reser.org>.
On Tue, Apr 2, 2013 at 10:06 AM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> Subversion solved this problem for their use case many many moons ago.
> I haven't seen anyone from subversion offer that solution back to the
> APR project, although that project depends entirely on apr/-util
> building. Why? Because it solved one specific use case, and it can't
> just be 'dropped in' as the apr solution. As you may have noticed,
> there are a number of build scripts authored by Mladen. But here
> again, they were written to address his immediate need, so they aren't
> so easily maintained or terribly flexible. PHP similarly created their
> own .js based autoconf for Windows, which also is not a drop in solution
> to the apr (-iconv/-util) puzzle.
Your maintainability issue is spot on. The Subversion project
solution hasn't worked out so well. Our Windows build is notoriously
difficult to use. We've actually discussed replacing the build system
with cmake and there actually is a branch (though abandoned) with
scons.
Everyone would be better served with a generic solution that someone
else is maintaining than one offs produced by the project.
Re: using new apr-util command-line make files... stuck on
apr-iconv
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Tue, 2 Apr 2013 17:50:45 +0200
Mario Brandt <jb...@gmail.com> wrote:
> 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?
Because no such offer exists to dev@apr? A quick review of 14 years of
email archives confirms this. (You might be confusing this thread with
another Apache project named Apache Web Server Project).
In this -specific- case of apr-iconv? Because the existing make files
(in the -src.zip package) are unlikely to ever need to change again?
And because we don't need another unmaintained tool? Maintainability
is the impetus to either finish the scons adoption that Paul started,
or to drive a cmake adoption which seemed to have some warm reception.
I'm partial to cmake but am not going to be hung up over which tool
for the job is selected, as long as a flexible tool for the job is
selected over more of the same.
Subversion solved this problem for their use case many many moons ago.
I haven't seen anyone from subversion offer that solution back to the
APR project, although that project depends entirely on apr/-util
building. Why? Because it solved one specific use case, and it can't
just be 'dropped in' as the apr solution. As you may have noticed,
there are a number of build scripts authored by Mladen. But here
again, they were written to address his immediate need, so they aren't
so easily maintained or terribly flexible. PHP similarly created their
own .js based autoconf for Windows, which also is not a drop in solution
to the apr (-iconv/-util) puzzle.
In the case of cmake, we end up with makefiles (which can even then be
generated in a unix roll/release script), but we end up with a whole
lot more. As long as cmake is maintained, you can have your Visual
Studio 2015 project files or Eclipse or other build tool build files
instead, if that is your preference as a developer.
So as I just wrote, checking in the 1.2.1 .mak files seems like the
clean and straight-line solution. It does not solve the other problem
on Windows of integrating apr-iconv with apr 2.0 (which was once the
apr-util -> apr-iconv -> apr dependency chain, now broken). It does
not solve maintaining apr-iconv, which is already missing Unicode 6
changes. I don't see apr-iconv living much longer as the reasonable
solution to this particularly useful apr(-util) xlate feature.
In the long term, dropping the apr-ism and adopting ICU, or BSD CITRUS
or another currently-maintained and AL-compatible iconv implementation
for xlate seems like the only reasonable way to go.
Re: using new apr-util command-line make files... stuck on apr-iconv
Posted by Mario Brandt <jb...@gmail.com>.
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 <gl...@gknw.net> wrote:
>
> > On 3/30/2013 11:14 AM, Jeff Trawick wrote:
> > > On Sat, Mar 30, 2013 at 2:10 PM, Gregg Smith <gls@gknw.net
> > > <ma...@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.
>