> > > 1/ as 'PRE' is a latin prefix which means before, would it be possible > > for > > > the sanity of the developpers to either: > > > a/ call it *before* the configuration is read. > > > b/ or rename it 'post_config';-) > > > then the 'post_config' can be renamed 'post_post_config';-) > > > > No, neither is possible. The pre refers to when we process the config, > > not when it is read. > > Argh. So I need pre/post_read_file hook maybe;-)
You don't need it in 2.0. The new config system was specifically designed to allow the type of thing that mod_macro does. > > > 2/ if the pre_config is to be run anyway after the configuration file > > is read, could you suggest another hook I could use ? I can't see > > any... > > > and the developper documentation is rather scarse and not up to > > date. > > > > > > 3/ or explain what I missed in the source code to understand the logic > > > behind all that. > > > > The easiest way to solve the problem you are looking at, is to mark the > > Macro directives as EXEC_ON_READ, > > I already needed that so as to be able to locate error messages, as the > cmd->config_file field is not defined otherwise, and I have to deal with > it. The problem is that I need an initialization *before* lines are > submitted to my commands, and this does not solve this issue at all. The register_hooks phase is run as soon as the module is loaded, so you can use that phase for your initialization. > > that will get the macros loaded while we read the config file. Then, in > > pre_config, walk the tree looking for the macro names, and replace them > > with the definitions that you read in earlier. > > It seems to me not to work, as you can have a macro definition within a > macro, which might be defined after macro expansion. That doesn't matter. I was actually wrong earlier, you don't want EXEC_ON_READ at all. The whole thing can be done without it. Just define a pre_config function. That function will walk the tree and find all macro definitions. Then, the second pass (not optimal, but easiest to explain) will expand all macros. Any macros inside a macro will be automatically expanded if coded properly. > Also, I have a problem understanding what you mean by 'walk the tree'. The > macro processing simply performs a macro expansion at the textual level, > which is parsed after expansion by modifying on the fly the config_file > structure with my own stuff... The Apache 2.0 config system has been changed, it no longer relies on the text file. Instead, the server reads the file into a tree that resides in memory. The server walks the tree to determine the configuration. By manipulating the tree before the server walks it, your module can impact the configuration. This is what the pre_config phase is for. > I can't see anyway a parse-tree for apache configuration file, given its > lexical structure... Is there such a thing? Take a look at the worker.c file, worker_pre_config function for an example of how to modify the configuration tree. > > Thus I think that it would be great if I had a pre/post read hook, > really?! > How can I get one? Or should I investigate the 'tree' stuff and try to > cast my stuff into that? You don't need a pre/post read hook, and I am very much against adding one. Please look at the configuration tree to solve your problem. Ryan
