httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject _selfish_ NT development requests
Date Tue, 14 Mar 2000 06:06:29 GMT
Ok... so I'm just asking for flames on this one :~}

<ALL>

The M$ compilers are very flexible in permitting precompiled headers to
streamline compilation.  The bulk of the pain seems to be in apr_config.h
and httpd.h.

The problem?  If the #includ'ed headers differ (sequence, omissions, or
whatever) it offers nothing.  Now, they aren't cheap (at about 4MB depending
on the includes...)

<NT>

So I'm first suggesting we kill the /XY and /Fp directives for all single
source file executables (rotatelogs.c and the like).  They are a waste.

</NT>

Next is more complicated.  If we lead each header with apr_config.h and
httpd.h (IN THAT ORDER) - we NT folk will save tons of time on compilation
(adding httpd.h to the /XY directive).  The problem, though, is that the
precompiled header of the core source files #define'ing CORE_PRIVATE is not
compatible with the header of the core source files that don't define it.
The sources linked to the core aren't consistent (and never would be in a
dynamic build environment).

I have a somewhat radical thought to solve it... is it unreasonable ACROSS
ALL PLATFORMS to compile the core binary with a define directive
(-dCORE_PRIVATE) rather than #define'ing it at the top of specific modules?
We could even call it CORE_BUILD or some such.  And, is it unreasonable
across all the sources to move the #include apr_config.h and httpd.h to the
top of the list, in that order, throughout?

This has the added benefit that NT (along with any other platform that comes
along requiring the API_EXPORT___ macros) can use a set of CORE_EXPORT___
equivialants, the apr lib can use a set of APR_EXPORT___ macros, etc...

The dllimport/dllexport pseudo-pragmas really impact the load time, function
and variable resolution and fixup code.  When it's a known dllimport, the
linker can call by reference rather than calling a thunk that calls by
reference.  Getting these cleaned up not only solves mod_info GP faults, but
optimizes the heck out of the whole package.  I imagine (but could be wrong)
that OS2 has some similar benefits.

</ALL>

Thanks for reviewing these thoughts...

Bill


Mime
View raw message