apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: using new apr-util command-line make files... stuck on apr-iconv
Date Tue, 02 Apr 2013 17:06:00 GMT
On Tue, 2 Apr 2013 17:50:45 +0200
Mario Brandt <jblond@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.

View raw message