httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject [patch] APR 2.0 - linkage mechanisms
Date Mon, 27 Mar 2000 05:45:45 GMT
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). 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_
 * I moved many includes by apr source modules to their internal, private

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 <> 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

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

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 <> 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 (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) 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 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

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

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.


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.

View raw message