httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: [patch] APR 2.0 - linkage mechanisms
Date Wed, 29 Mar 2000 04:51:32 GMT
> > 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.
> I thing I grok what you are trying to accomplish here and am
> +1 for it.
> However, no one has time to sift through multiple patches to
> distill this
> one change. Where does the copy happen? Point me to the code.

See apr.dsp for this change.  apr.dsp will not build a .dll, but the
source for the library.  See aprlib.dsp for the very simple .dll
builder.  Note that apr.dsp makes one of four targets, two are
Standalone.  But aprlib.dsp builds only one of two, Debug and Release.

> Both of these were on my todo list. It would have been much easier for
> reviewers if this were submitted as a self contained patch.
> Since I was looking at the code, I made the changes.

Ok... but given the method you chose, would you also blast
UnixTimeToFileTime(), since it isn't reference from anywhere?

> > 21) The dll's .def file now carries a version, a base address and
> > description.

> I'd really like to see this as a seperate patch.

Then drop it for today, I believe it hurts and helps nothing now.

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

> Easy to grok.

Knew that one would be :-)  Let's knock of 21/22 later, together.

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

> Warming up on this one as well.

Asked greg for permission to post our ongoing stream of thought,
it might help you jump into the fire.  Note it really does nothing
if you don't ask it to - ergo it's harmless to the command shell.

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

> Huh?

OK - file change must be applied to prevent
walks through dependency trees.

If you make a .mak file from a .dsp project,
-AND- you have more projects loaded in the workspace,
-AND- the .dsp depends on one or more of the loaded projects

the .mak file will contain commands to make that sub-project.
Great for Greg, me and the rest of the world *WHILE* we work
within in the IDE.  It is even a great command line thing!

I used the feature for aprlib.dsp so the apr.dsp would be build
automatically.  I don't like it, and the next group of -small-
patches will fix it.


Where is this going?

Look at the compiler defines.  Each will have a package specific
tag of some_IMPORT_DLL, some_EXPORT_DLL, or no tag for that library.
Obviously, there is a ton of code to fix to change API_EXPORT_*&$@
tags.  They don't isolate the seperate packages.  You can't suggest
that ap_get_curtime(), ap_base64decode() and ap_process_connection()
are ever in the same package, yet they carry the same tag!?!

One issue this raises is that the includes must be layered in the
right direction.  It also increases readability to see right off
the bat that a source module's first #include of <apr_config.h>
tells everyone it _MUST_ be part of the apr package!

Likewise, <ap_config.h>/<httpd.h> should tell us we are in Apache.
If Apache is always based on apr, the FIRST thing that ap_config
should do is include <apr.h>.  No questions, no confusion, no
crossed up declaration sequences, and nobody's preferences are
trompled on by different packages.


So approach this HOW?

I guess the order of application is, check out the apr-xplat.diffs
fixes.  That will pre-resolve all the bugs you would run into
running any other fix.  Plus, since I don't know if it breaks unix,
I need someone else to look.  You might, at that moment, need to
look at the next issue in tandem (including apr.hw from within
apr_config.hw for unix).  If these work, don't worry that win32
does or doesn't build.

Next take a close look at apr.hw/apr_config.hw and the autoconf
macros.  Seriously consider cleaning up the overlap between
public and private - but at the least check my work.  Then
include apr.h from apr_config.h.  At this point, obviously, you
need the apr.dsp/aprlib.dsp to even make the .hw files into .h.
And decide if you like the topical grouping of source code
(subfolders of each group).

Note this step adds compiler declares you won't see used for a
month.  Live with that so we don't revisit it later.

And adopt the new  These build
a two tiered .mak structure so we can evaluate its effectiveness.

Also decide if you like apr.dsp/aprlib.dsp file locations.  Note
that the ultimate target of the aprlib.dsp is right back to
where it is today.  Each .dsp I touch will know to look in either
location, so that once all is done we can just touch the file
over to the src/build tree.  I already decided to move the apr.lib
output from just the Win32 Debug and Win32 Release folders out
from ~~~/apr/dll out to ~~~/apr/dll/link or ~~~/apr/dll/obj/link,
so that once we build aprlib.dll and aprlib.lib into ~~~/apr/dll,
this pre-library won't confuse people.  The Win32 Standalone...
models are already correct.

Finally apply the rest of the winsrc.diffs.  These are source fixups
that must happen, but only for win32.  Sorry, again, if I crossed up
fixing real bugs with structural changes.

View raw message