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: Compiling and using apr_dbd_sqlite3
Date Mon, 05 Jul 2010 03:49:19 GMT
On 7/4/2010 4:52 PM, Sam Carleton wrote:
> On Sun, Jul 4, 2010 at 1:27 AM, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote:
>> On 7/3/2010 8:53 AM, Sam Carleton wrote:
>>> Why?  why why why?  I simply don't get it
>> Sam, please don't waste your energy venting at APR or any other open
>> source effort, take your issues to MS just as we've all tried.
> So if it is Microsoft stopping you

No Sam, the VC team has done all they can to impede, not to 'stop' open
source projects from offering consistent, interoperable behavior.  I'll
limit my reply to speak to the actual issues, rather than the rest of the
silliness in your rant.

The science of binary versioning of a single shared library resource was
solved a very long time ago, so it's strange this still is not applied
sensibly for such a critical, common requirement as C language applications.
Somehow, all the rest of the MS OS related teams are held to such a basic
requirement, so it's just puzzling.

At the time 2.2 binaries were -first- released, there was not quite an
entirely free solution to building these, and whichever choice of a more
modern compiler was picked would have resulted in lock-in to that flavor.
At that time, Perl and Python from ActiveState were on two different versions,
neither on msvcrt.  The 'lite' (free) flavor of the compiler shipped a crippled
toolchain, with basic tools missing from the collection.  And so, we are stuck/
sticking with the flavor first shipped as 2.2, so that modules which already
interoperate continue to keep doing so, until 2.4 (or even 2.3 betas) ship.

Now there are Strawberry Perl and other alternatives, and now that there are
more solutions today, now that the 'express' flavors include the various
toolchain components, and the DDK team continues to find ways to provide the
msvcrt.dll functionality, as your link points out.  It becomes a question of
what the best choice is, and you are writing to the wrong list for that whole

But there are reasons the tone of your post falls on deaf ears.

One, you are on the wrong list.

Second, this is Open Source Code; we welcome you and everyone who likes to
compile it exactly as you like, and we've put no impediments in your way,
even done what we can to deal with different versions of windows, msvc (and
gcc, sun cc etc etc etc).  The binaries are just a convenience, if they are
created at all, they have nothing to do with the development and promulgation
of the Source Code we are providing to the public at no charge, which is our
entire purpose.

View raw message