A nice extension to the IfModule directive would be to allow it to compare against the symbol name (rewrite_module) or the .so name (mod_rewite.so), instead of only relying in the .c name (mod_rewrite.c).. This will make it easier to write a config file for modules while have the core .c named something else (ie. sapi_apache2.c).
Agreed. This disturbes me all the time, too :-)
I see several ways of solving this issue. 1) Create an Ifsymbol directive which is analogous to IfModule except it searches mod_so's internal dynamically loaded modules (moduleinfo structs). 2) Similar to 1 and have IfModule call a function in mod_so (via an optional function) to search mod_so's internal list of dynamically loaded modules. 3) Alter the STANDARD20_MODULE_STUFF macro to take one paramter which is the *filename* to register.. (ie.. for sapi_apache2.c sepcify mod_php4.so instead) This can be setup as a NAMED macro and have the standard one call the NAMED with __FILE__ to retain backword compatability. 4) provide an function to be called by a modules register_hook function to register alternate names and have the ap_find_linked_module search this list as well.
Created attachment 11620 [details] Patch for solutions 1 and 2
Created attachment 11621 [details] patch for solution number 3.
Set PatchAvailable I still need to work up a patch for solution number 4.
Created attachment 11670 [details] Mixed variant
I've attached a patch against HEAD partially based on yours which leaves it all to <IfModule>, but also resolves the static stuff. Opinions?
Created attachment 11685 [details] Updated patch switching mod_so.c to use the ap_module_symbol_t structure
It looks good.. and solves the issues I brought up before.. my updated patch just has mod_so use ap_module_symbol_t instead of it's privately declared version of that structure (moduleinfo) no need to have two copies of the same structure. I think this solves the issue completely, I'm up for bringing it up for a vote on dev@httpd.
+1. (plus that the build processes for win32 and netware need to be updated).
Created attachment 11690 [details] win32 patches
Committed, since nobody cried. The build is broken now on Netware, but I assume, it will be fixed soon.