httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: cvs commit: apache-2.0/src/include ap.h ap_base64.h ap_hooks.hap_sha1.h
Date Sat, 27 May 2000 05:59:28 GMT
> From: Greg Stein []
> Sent: Friday, May 26, 2000 11:37 PM
> On 27 May 2000 wrote:
> > wrowe       00/05/26 21:23:26
> > 
> >   Modified:    src/ap   ap.dsp ap_base64.c ap_sha1.c ap_hooks.c
> >                src/include ap.h ap_base64.h ap_hooks.h ap_sha1.h
> >   Log:
> >   
> >     ap.h is the basis for the ap.lib collection.  Since it 
> is a distinct
> >     package, this patch provides appropriate Win32 linkage 
> resolution for
> >     its functions and data.
> What the heck? It is NOT a distinct package. Didn't you just discuss
> earlier today, the desire to fold src/ap/ into src/main/?

Yup... haven't seen anyone comment on that request, though.  (Not 
actually expecting it done... simply comment one way or the other
if someone had the [dis]inclination to commit that change.)

> Now you've gone and switched all the macros to AP_EXPORT. 
> Once that shift
> is done, then they have to be changed *BACK* to API_EXPORT.

More specific... the three modules and their headers change back to
API_EXPORT, and they lose ap.h entirely.  The fixes earlier today 
(much appreciated, Ryan, by the way!) tied up the solution into the 
wrong header, IMHO.

> Needless work!

True... but a worthwhile thought exercise into exactly how the entire 
core is linking and interacting.  The crux... I am trying to yank
http_main (just a bunch of static funcs plus main()) into what we
Win32 folk think of as Apache.exe.  There were oodles of side effects.
This cleanup is targeted at preventing those kinds of faults by tying
each component into it's own linkage symbols (a major reason for my
becoming a contributor in the first place :-)

> >     The most significant change is in the ap_hooks.h 
> declaration macros.
> >     These now require a first parameter of the linkage to 
> be used.  There
> >     is no shared data, so only the hook-in and hook-run 
> functions are
> >     affected.  Use the appropriate function export without 
> the parens,
> >     for the core server this will be API_EXPORT (no 
> variable args, and the
> >     functions are exported from the core server.)
> Hunh? Presuming that only the core is going to define the hooks, this will
> ALWAYS be API_EXPORT. There really should be a simple form of the hook
> macros that stuffs in API_EXPORT. If you want an extended form, then
> great.

In fairness, you are assuming only the Apache new-httpd server will
use the hooks.  True - they are not APR (although I think with this
change they aren't as far from being vanilla.)  But it is useful code
in many respects, outside of this single instance.

We are also assuming that the ApacheCore remains a single entity.  I'm
not about to change that, but for a single token, it doesn't hurt to
keep the doors unlocked.

> But don't go and start changing all of the files to insert 
> over the place in these hook things. Bleck.

Bleck true!  It isn't pretty.  I got this down to a single extra arg
where I once was looking at two args, and it clarifies who owns the
hook.  Will we have dynamic modules loading modules at some point?
Who knows...
> Grr. This is a mess. I'm not liking this change you made at all.

Fair.  Let it digest... I'll follow this thread again by noon tommmorow.

If someone gets a chance to roll src/ap over to src/main, then great,
I'll bite and finish off the Win32 part (as I offered before).

If there is a concensus that the extra arg to hook declarations are
unacceptably ugly, I'll revert that change back out.

I am assuming that your complaint isn't against assigning each modular 
package its own export tokens, however.  Please, correct me if I'm wrong.


View raw message