On Tue, 2 Apr 2013 17:50:45 +0200 Mario Brandt <[email protected]> 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.
