On Tue, May 17, 2011 at 9:19 PM, William A. Rowe Jr.
<[email protected]> wrote:
> About the patch, yes this should go in.  I'm busy for a day or few
> but flagged your message to come back to it, if there is a bugzilla
> incident please tag it 'depends on' PR 49997.
>
> On 5/17/2011 11:10 AM, Jorge Schrauwen wrote:
>>
>> Do the argument from a few year back still hold for the ASF not
>> providing them themselves still hold true for 2.3/2.4?
>> IIRC it had to due with VC6 being used for 3rd party module
>> compatibility. With the release of 2.4 series around the corner maybe
>> now is a good time to discuss this again?
>
> Correction; VC6 was used for *source file compatibility* within the
> build.  dsp/dsw could be exported to makefiles, or loaded by later
> Developer Studio versions into vcproj/sln format.  It was the only
> 'one single representation' that worked.
>
> For binaries, we used the MSVCRT which could be linked using VC6,
> but not safely by VC7 or later without DDK include files corresponding
> to the NT team's MSVCRT (rather than the compiler team's MSVCRxxx mess).
> Too many things relative to the MSVCR binaries are macros with all sorts
> of static assumptions.
>
> If I start preparing binaries for 2.4 to www.a.o/dist/httpd at all,
> it would be both 32 and 64 bit, and will either be Mladen's suggested
> WinDDK approach (using system MSVCRT) or the VC10 SP1 (current) way,
> still using industry-standard make/nmake, not msbuild nor gui proj.
>
That's good news, I had a chat with Guenter Knauf about this mess during FOSDEM,
We briefly discussed LLVM but I never got it working (most likely due
to time reasons).

I have no strong opinion on going VC10 or WInDDK... as long as the
users can get both flavors of binaries here.

> We may have reached the fork in the road where it no longer makes sense
> to maintain both a gui dsp/vcproj and makefiles from the studio solution.
> VC 7/2002 dropped support for exporting makefiles; VC 10 drops support
> for converting dsp/dsw into vcproj files.  So if we want either dsp/dsw
> or vcproj/sln files, we may be at the point of adopting the subversion
> approach to generating these gui representations from makefiles or
> resources common to the unix build, as the apr project generates from
> the .
>
> We also continue to improve the interoperability with mingw/msys.
>
> Due to project and personal trolling, I've put the rest of the opinions
> on this (and certain individuals) into the /ignore list for now. I am happy
> to continue this dialog of what MS got wrong in the WinDDK approach,
> and why it may be just too much effort to ask users to assemble such
> a toolchain with comprehensive msvcrt link .lib's, and simply go with
> the VC10 optimizations and library (WinDDK includes a VC 9 generation
> of the compiler).  MSVCRT is the kindest to our users consuming the
> software, but VC10's MSVCR100 is much kinder to module packagers and
> developers who wish to link to the same clib with minimal pain.
>
Indeed a system MSVCRT would be cleaner,... but if I look at most of
my windows machines they have a whole set of runtimes installed raging
from 2005,2008,... usually with and without SP's...

Chances are the end user will already have whatever version is needed.
Personally I think having it easier for the developers to link their
binaries would in the end be better for the user, since more modules
will be available for them to use (in binary form).


Jorge

Reply via email to