httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Windows Laundry List
Date Tue, 17 May 2011 19:19:37 GMT
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.

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.

View raw message