On Saturday 15 May 2010, William A. Rowe Jr. wrote:
> On 5/15/2010 8:03 AM, Stefan Fritsch wrote:
> > Yes, I think that's ok. In any case I would like to hide the
> > mod_foo.c from the user as far as possible and use the name of
> > the module struct (minus the trailing _module). The LogLevel
> > directive in my patch already accepts foo, foo_module, and
> > mod_foo.c as names for the module.
>
> This is goodness; I'm still concerned about the mechanics of the
> implementation, as I mentioned in Wicklow. How to avoid the
> developer needing to preset a define?
>
> One way, admittedly as awkward as your design but meeting the style
> guidelines, is something of an executed macro, e.g rather than
> initially setting #define AP_MODULE_VAR authn_dbm_module, it
> becomes something like AP_MODULE_NAME(authn_dbm_module). If we
> decide next time around it's a static, so be it. If it is the
> address of the module struct, great.
What about making it a requirement to use a macro for the module
struct definition? Something like
AP_DECLARE_MODULE(foo) = {
STANDARD20_MODULE_STUFF,
...
}
would then expand to
extern module AP_MODULE_DECLARE_DATA foo_module;
static int * const aplog_moduleindex = &foo_module->module_index;
module AP_MODULE_DECLARE_DATA foo_module = {
STANDARD20_MODULE_STUFF,
...
}
http_log.h would then contain:
extern static int * const aplog_moduleindex;
#define APLOG_MODULE_INDEX *aplog_module_index
Would compilers be able to optimize this variable away? In multi-file
modules, one would use an additional macro
APLOG_USE_MODULE(foo);
which would expand to
extern module AP_MODULE_DECLARE_DATA foo_module;
static int * const ap_log_moduleindex = &foo_module->module_index;
For 2.2.x it would be easy to define compatibility macros to make a
module source compatible with both 2.2 and 2.4.
> I still don't care for the approach, except perhaps for the author
> af a multi source program. Something will need to associate
> foo_util.c to foo_module with the base source of mod_foo.c. But
> for single source mods, it's still too invasive.
>
> I'm interested in how this puzzle can be generally solved with
> __FILE__, with the module structure address, and at the load
> module/register hooks phase.
>
> We agree that mod_foo.c or foo_util.c should be hidden from the
> user, but is there a way to associate the string address of
> __FILE__ (as a constant, can we trust today that all compilers
> will optimize this within a single source .c file?) at the module
> registration phase? With that list handy, -we- can go to the
> trouble of mapping foo_module into an entry for mod_foo.c (and
> foo_util.c, if necessary).
I agree that this would be nice, but I haven't found a way so far.
BTW, I wouldn't want to rely on the fact that the string address of
__FILE__ is a single constant per file. It would be really annoying if
httpd behaved differently with optimization turned off.
