This has always been a thorn in my side :) I actually proposed about 2 yrs ago that we change from <IfModule source.c> to <IfModule structname> since it's easier to identify the structname. At that time, it appeared to be challenging, and I had proposed a patch that would capture the structname in the process of declaring it with STANDARD20_MODULE_STUFF.
But this turns out to be a much more trivial problem to solve. I'd propose we collect *both* the source.c from the module structure, as well as the structname *at the time we loadmodule*! (This is slightly more complicated for compiled-in modules.) I'm -0.5 against another named container <IfSymbol > - we recently kicked around the issue of proliferating namespaces. Because most sources for module names end in .c (or .pl etc) there should be little overlap with the structure names for modules. The theory is trivial, it's much easier to say; LoadModule foo_module modules/mod_foo.so ... AddModule foo_module then to figure out that mod_foo.c, foo.c, or foo_setup.c is the module which declared that STANDARD20_MODULE_STUFF. So each module will have two entries in the lookup table, but that doesn't appear to be a huge problem. The items you detail below are all interesting solutions to forcing the top sourcefile name to be mod_php.c for example, but they don't get at the real crux of the problem, which is that users shouldn't have to know source names, and *already* know the structure name, by virtue of seeing the LoadModule directive for the module documented, somewhere. Thoughts? Bill At 10:59 PM 5/20/2004, Edward Rudd wrote: >I've posted 2 patches and listed several solutions to my bug # 29003. >This bug is a feature request addressing the common issue where a module >does not follow the standard naming of module source code names.. >(mod_modulename.c), but instead use something else (sapi_apache2.c). > >The first solution is to add an IfSymbol directive to search the symbol >names of dynamically loaded modules. (via mod_so). > >The second is similar and patches IfModule to use an optional function to >hook into mod_so's internal list of dynamically loaded modules as well. > >The third option is to create a STANDARD20_MODULE_STUFF_NAMED macro which >one can specify the filename to store in the module structure (instead of >__FILE__). > >The last solution I saw was to create a function to register aliases that >the ap_find_linked_module function will search as well as the module >structure. (ie.. register mod_php4.c to point to sapi_apache2.c ). > >Let me know your thoughts on these ideas.. and any other are welcome. >I currently have patches attached to the bug for solutions 1 through 3. > >Regards, >Edward Rudd
