On 5/15/2010 8:03 AM, Stefan Fritsch wrote: > On Friday 14 May 2010, Jeff Trawick wrote: >>>> For selection by module, does the facility need to be more >>>> granular than simply using the canonical source file name -- >>>> the name of the file that declares the module struct? >>> >>> I am not sure what you mean. Somehow it must be clear what module >>> is to be used for logging. >> >> I just meant: Is it okay that, for example, the foo module is >> always known as mod_foo.c as far as logging concerned, whether the >> current source file is mod_foo.c, foo_cmds.c, foo_proc.c, >> etc.? And you wouldn't be able to configure differenting logging >> for mod_foo.c logging vs. foo_proc.c logging? >> >> (It is okay with me, and perhaps that's what you were planning >> anyway.) > > 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. 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).
