httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: [patch] APR 2.0 - linkage mechanisms
Date Tue, 28 Mar 2000 18:48:18 GMT
Reviewing apr-winsrc.diffs...

We do not need FileTimeToUnixTime().  The time values in file_t should be in
APR time (use FileTimeToAprTime). Also, your conversion to
AP_DELTA_EPOCH_IN_100NS is off by a factor of 10 in the routines where you
use it. I will rework the patch the commit it.

Bill

----- Original Message -----
From: William A. Rowe, Jr. <wrowe@lnd.com>
To: <new-httpd@apache.org>
Sent: Monday, March 27, 2000 12:45 AM
Subject: [patch] APR 2.0 - linkage mechanisms


> APR overhaul for linkage mechanisms stage 1 is complete.  It builds a
static
> lib or dynamic dll on Win32.  There are no significant errors emitted.  It
> is happy (well, all but signed/unsigned warnings and a linker warning to
fix
> when I get to support/ - but I had to stop somewhere and leave something
for
> others to address :-)
>
> I know you are all cringing.  I would have too if I knew when I started
> where I would end up.  Unfortuantly, it would take two weeks to layer on
> these changes a bit at a time without breaking anything, and another 10
> hours of analysis to find additional code subsets that can be
independantly
> changed.  I've carefully avoided even touching anything outside of apr at
> this moment to make it less painful.  What I have touched beyond apr can't
> be avoided.
>
> It was tested using the src/modules/standard/mod_include.c pre-rbb's
update.
>
>   apr-xplat.diffs are apr cross platform code and header fixes
>
>   apr-winsrc.diffs are win32 specific code, headers and dll defs
>
>   apr-winbuild.diffs reflect win32 project/makefile/workspace changes
>   (because many are out of date, all win .mak files were regen'ed
>    to reflect the current headers from the current .dsp's).
>
>   apr-newfiles.zip is to be unzipped into apache-2.0/src.  I can not
>   for the life of me force cvs -N diff to do anything useful.
>   These file add/deletes that I couldn't put in the .diffs are:
>
>   + apache-2.0/src/Apache.dsw
>   + apache-2.0/src/lib/apr/apr.dsp
>   + apache-2.0/src/lib/apr/apr.mak
>   + apache-2.0/src/lib/apr/aprlib.dsw
>   - apache-2.0/src/lib/apr/include/apr_win.h
>   - apache-2.0/src/lib/apr/include/apr_winconfig.h
>   + apache-2.0/src/lib/apr/include/apr_config.hw
>   + apache-2.0/src/lib/apr/include/apr.hw
>   - apache-2.0/src/lib/apr/misc/win32/timetest.c
>   + apache-2.0/src/lib/apr/misc/win32/aprlib.c
>
>   apr-configs.diffs.txt IS NOT real diff to this patch.  It is the
>   human-readable diffs of apr.wh and apr_config.wh from their old
>   existance.  I hope this helps those reviewing the patch.
>
> I really hope this makes the comparison manageable.  On windows though,
they
> are all intertwined.  Here is the stratagy:
>
> *** The following changes affect all platforms ***
>
> 1) Delete apr_win.h and apr_winconfig.h from distrbution.  Stop using
them.
> Win32 now clones apr.hw and apr_config.hw for the proper apr.h and
> apr_config.h files.  Today it creates temporary apr_win* files.  After all
> apache sources are cleaned up, we eliminate the temporary clones
> apr_win/apr_winconfig entirely.
>
> 2) The apr.hw and apr_config.hw files are now organized to better reflect
> the autoconf sources.
>
> 3) The internal apr_config.h (.hw) now includes apr.h.  See the _Next
Phase_
> below if you will help cleaning them up to work together in the
autoconf'ed
> versions (Warning: this could have already broken the Unix APR).
>
> 5) By leading every internal apr source file with apr_config, we assure
that
> we stay in the target library config.  We are assured apr.h won't occur
> before apr_config.h, and tangle the logic.
>
> 6) I walked the include chains and minimized many of them, except
> apr_portable.h for clarity.  Everyone should now flick through the build a
> bit faster.
>
>  * I especially stripped out <sys/types.h> and <windows.h>, given they
live
> in apr/aprconfig.
>  * Corrected the "apr_winconfig.h" "apr_win.h" stripping out the #ifdef
> WIN32's, but only across win32 apr.  If I touched a non-apr, then I fixed
> it.  If I had no other reason, that's the next phase.
>  * Where I noticed, I also tripped headers with their appropriate HAVE_
> macros.
>  * I moved many includes by apr source modules to their internal, private
> headers.
>
> 7) These changes broke serveral non-apr sources.  For today, I simply
> propose to assure that ap_config occurs first, then httpd, and then
desired
> apr_* headers.
>
> 8) The flow of declaring ap_get_oslevel, where applicable, is now
>
>  * define ap_oslevel_e in the apr.h
>  * define HAVE_OSLEVEL in the apr.h
>  * the conditional function declaration in apr_general.h is constant.
>
> *** The above changes affect all platforms ***
>
> --- Remaining changes affect simply the Win32 port ---
>
> 9) Since Unix won't add std headers (except sys/types.h) to
apr/apr_config,
> so neither will win32 (anymore).
>
> 10) Unix programmers don't have reason to include <windows.h>, so
> apr/apr_config will.  Caviat, I included the entire exclusion list for the
> individual components.  Not much is included anymore.  We even invent
> SH_SHOW so we don't have to trudge through an extra set of winuser.h
> headers.  btw - windows.h already grabs winsock/ws2 headers.
>
> 11) Including the restricted subset of <windows.h> could be a very bad
thing
> to external source modules.  So the public apr.h emits a build message if
it
> if the first to include windows.h.  This should occur in the including
app's
> own config or headers before attempting apr_anything.
>
> 12) We now effectively precompile our apr_config for all apr.dsp sources.
> Precompiliation explicitly stops after apr_config.h
>
> 13) Unix lives on the HAVE_???_H, so we expanded that list for win32 (if
> someone wants to recheck it please be my guest!)
>
> 14) aprlib.dsp is nothing but a shell of it's former self, it's simply the
> .dll linker.  It does has a empty dummy module to work around the warning
> LNK4001, no object files to link.  It simply links the shared apr.lib into
> it's dll form.  You must load this project in a workspace that reflects
its
> dependency on apr.dsp.  I've included a simple workspaces
apr.dsw/aprlib.dsw
> for this purpose, but if you roll your own .dsw beware!
>
> 15) apr.dsp is the compilation workhorse, and has two extra configs, Win32
> Standalone (debug and release).  These will soon appear in a support/ .dsp
> files for those apps.  aprlib.dsp which creates the .dll knows nothing
about
> them (and that's a _good_ thing!)  We do not build apr.mak for the normal
> Debug/Release versions - aprlib.mak does this for us.
>
> 16) Adopted Greg Marr's <gregm@alum.wpi.edu> build tree patch, so the
aprlib
> and apr play nicely in the apache-2.0/src/build/win32 tree.  Both apr
debug
> and release dlls land to their old homes for a while, so we don't break
> Apache (we will warn Apache to search both locations before changing
over).
> If well recieved we will proceed to the rest of apache.
>
> 17) To assist Win32 coders in getting up to speed, the project presents a
> set of folders by function group (mirroring the tree).  It also indicates
> Internal Headers seperate from External Headers.  It reflects that
> apr/apr_config files are Generated Headers, and they carry _lots_ of
> warnings.
>
> 18) WinTimeToUnixTime is gone (unlucky bugger).  The functions are now
> FileTimeToUnixTime and FileTimeToAprTime, and neither is exported.
Really,
> WinTime?  Which of the dozen are we talking about :-?  Saving several
double
> divides, we now work from 100NS units straight to ap_file_t or file_t.
>
> 19) delete timetest.c - FileTimeToUnixTime is now in time.c with it's
> friends.  Looks might we are already overboard with possible dup
functions,
> but that wasn't what I was cleaning for.
>
> 20) Both .dsp projects, all configs are told to share the same source
> browser file.  This will substantially help new contributors figure out
the
> big picture.  It is only built by the apr.dsp - Win32 Debug configuration.
>
> 21) The dll's .def file now carries a version, a base address and
> description.
>
> 22) ap_oslevel_t now has gaps to define additional sub-revisions (if we
> later find we need them for specific api calls), the versions are now
> sequential for easier feature testing (>= NT can catch NT2K and avoid 9X)
.
>
> 23) Adopted Greg Marr's <gregm@alum.wpi.edu> Apache.dsw to make the big
> picture easier to read.  It isn't told about logresolve.dsp, which doesn't
> exist, htdigest.dsp, which is broken, or the broken Modules.
>
> 24) Every module in makefile.win (except aprlib) is set with RECURSE=0 so
we
> are still in total control of the build flow, and no extra NMAKEs are
> invoked.   Since only aprlib should ever know how to build the standard
> apr.lib, aprlib it told RECURSE=1.  Later we will build apr.lib with a
Win32
> Standalone target, but the modules using it will have to target Win32
> Standalone as well.
>
> 25) makefile.win has a new uninstall tag to clean out the installed
> executables, and remove my mess when I drop binaries in my root apache
tree.
> It also came in handy for...
>
> ...ahhh, almost there...
>
> 26) and makefile.win has a new precommit (thrash itself until you are
> certain it all builds, then clean up entirely) target.  It will go so far
as
> to attempt _EVERYTHING_ possible.  A little >makefile.log tacked on when
you
> invoke nmake will assure you read any warnings or errors.
>
> Next Phase
> ----------
>
> I'm not suggesting the cleanup discussion between rbb/bill is anywhere
near
> complete.  (But these changes make it easier for everyone to move
forward.)
>
> Unix aught to be modified to include apr from apr_config, after all
> apr_config controling declarations.  (See the .hw's for the Win32 flow.)
>
> apr_config should be scrubbed of everything that should be exposed in
apr.h,
> and everything private should be scrubbed from apr.h.  This is a job for
an
> autoconf'er, but I will be happy to mirror the .hw's.
>
> support/ files will invoke the Win32 Standalone Release build to create a
> link library rather than a dll import.
>
> After all .dsp projects set the correct flags, the APR_DLL_IMPORT and
> APR_DLL_EXPORT will replace the API_EXPORT stuff in there today with
> APR_EXPORT tags.
>
> Tons of changes will then be applied to declare all the exports with the
> APR_EXPORT tags, including a huge number that are not correctly tagged
> today.  The .def will be washed clean then.  I will work up the version
> control call to allow the app to validate that the DLL is an acceptable
> version.
>
> After Apache and ApacheCore and the modules are looking also to the new
> locations for the aprlib.dll in the new tree, it will move to
> build/win32/dll/apr/release and build/win32/dll/apr/debug.
>
> Requests
> --------
>
> 1) Please review, comment, commit, flail, abuse etc...
>
> 2) If you are an autoconfer looking for work please look at the
apr_config.h
> inclusion of apr.h and general cleanup above.
>
> 3) Should canonical_filename be exported, or changed to an ap_ style
> declaration, or deleted?
>
> 4) What is apr_slack doing in there?  This is anything but generic and
isn't
> used by the rest of apr, so it misses the APR mark from all I can see.
Back
> to ap with it?  IMHO, APR should _never_ reference an external product,
even
> the  Apache server core (when we get there, we need to look back to where
we
> took the wrong turn.)
>
> 5) Will someone draw me a quick flow chart of the currently used
combination
> of the apr's configure (what's the top level?  What files might now be
> dead?)  I want to document it clearly enough for Win32 folks to know when
> they are touching something related to the autoconf.
>
>
>


Mime
View raw message