On Sat, 11 Dec 2004, Stas Bekman wrote: > [subject change] > > Randy Kobes wrote: > > >>The only minor problem is that I had to duplicate code from APR_Pool.h: > >> > >>/* XXX: the mpxs_cleanup_t and mpxs_cleanup_run are almost dups with > >> * code in APR__Pool.h (minus interpr member which is not used > >> * here. They should be moved to modperl_common_util - the problem is > >> * modperl_interp_t *, which can't live in modperl_common_* since it > >> * creates a dependency on mod_perl. A possible solution is to use > >> * void * for that slot and cast it to modperl_interp_t * when used > >> */ > >> > >>Anybody wants to tackle this? I think the pool stuff is still dependent > >>on mod_perl, since it has modperl_interp_t in it. > > > > > > Here's a partial stab at this, moving mpxs_cleanup_t to > > src/modules/perl/modperl_common_types.h: > [...] > > ====================================================================== > > I'm looking at doing the same for mpxs_cleanup_run, but > > am having a problem at the moment with getting the > > declaration of modperl_opt_interp_unselect in the right > > place. > > Thanks Randy. > > Heh, I did that part too and but gave up on the > modperl_opt_interp_unselect :) > > What I don't get is how does it work now if APR::Pool references > modperl_interp type inside of it and it sort of works w/o modperl.
That occurred to me too ... APR::Pool must see the definition modperl_interp_t (with or without the moving of mpxs_cleanup_t to modperl_common_types.h), even though (presumably) it doesn't need mod_perl (I suppose due to the conditionals present that test if an "interp" exists). But does this mean there's a (weak?) dependency still in APR::Pool on mod_perl? -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
