On Friday 19 March 2010, Jeff Trawick wrote: > This seems to be the change necessary in most modules: > > +#define APLOG_MODULE_INDEX access_compat_module.module_index > > ( > BTW, this one seems to be slightly borked: > +#define APLOG_MODULE_INDEX > optional_hook_import_module=.module_index ) > > Having access to the module_index from any httpd or module-specific > macros invoked in the module is potentially useful for diagnostics > other than logging. Also, requiring that macro to be defined in > order to log isn't much easier on the module than requiring that > macro to be defined in order to be a module at all (since most > modules log at one point or another). What about calling it > AP_MODULE_INDEX (or maybe AP_MODULE_VAR for addressability to the > module structure), and formally requiring it to be defined before > the inclusion of SOMETHING.h, with #error generated otherwise?
One could imagine to have code not related to any module use APLOG_MODULE_INDEX == APLOG_NO_MODULE. But in the patch I have not done that but used core_module.module_index instead. We could define the API in a number of ways: - require AP_MODULE_VAR to be defined, #error otherwise - require AP(LOG)_MODULE_INDEX to be defined, #error otherwise - if APLOG_MODULE_INDEX is not defined, define it to APLOG_NO_MODULE and print a warning (though #warning seems to be non-portable) I am fine with any of them, but now that you have pointed it out, I agree that the first alternative seems to be the most generally useful. > (It wasn't 100% clear to me that APLOG_MODULE_INDEX was an absolute > requirement for logging. Is it? As the patches are written right now, it is. But it need not be the case, if we choose the last alternative given above.
