dynamic cfghelp

[Former user]

Copied from #45 in old bug database.

Some discussion here: http://forums.minegoboom.com/viewtopic.php?t=5025

grelminar:

Currently cfghelp is processed out of source files by a script, and compiled statically into the main asss binary (although you could theoretically load another module that registered a new cfghelp implementation).

Ideally, it should be fully dynamic, like the command help system.

The fundamental problem is that you have to register and unregister commands, so there's a a logical place to sneak in a pointer to some text. You might consider adding a helptext argument to Get{Int,Str}, but then the server has no way of knowing if your module gets unloaded.

A more likely solution might be this: in the makefile rules for compiling a .c file containing a module into a .o file, add commands to run a script over the .c file looking for cfghelp text, and if there is any, output a temporary .c file that contains static data, named with the module name, with the processed representation of the cfghelp, compile it, and do an incremental link with the original .o file. Then, when loading modules, do a dlsym for "foo_cfghelp", and if it's there, pass the pointer to the cfghelp module (this is a gross special case in cmod). Keep the pointer around, and deregister it on module unload. Pros: it might actually work; it doesn't require module writers to do anything different. Cons: it'll be a pain in the ass to get working on windows; it's sort of gross.

For python modules, it's a little easier, or at least less gross: when loading a python module from a .py file, run a cfghelp-extracting script right then (let's require it to be present in bin), which will pass the data it finds to cfghelp. Keep references to it, and unregister it on module unload.

Dr Brain:

What's the problem with just having RegisterCfgHelp() and UnregisterCfgHelp()?

grelminar:

It would be really really annoying. Which means it wouldn't be used as much as it should be.

Seriously, do you want to have to touch four separate parts of code each time you add a setting? You'd have to add the line that does the GetInt/GetStr, deep inside some function. Somewhere at the top-level (far from the GetInt/GetStr), you'd have to add a "local helptext_t foo_cfghelp = ...". Then you'd have to add RegCfgHelp and UnregCfgHelp calls. I'm much rather have a special comment located right at the actual use of the setting.

Dr Brain:

Well, the solution you're proposing will result in more or less the same binary code. You'd just have it so that you create one comment and it automagically happens. All things considered, I'd rather do it myself with the two extra lines. Then I won't have to worry about funky python parsing errors or making sure the comment is formatted properly (which I always get wrong).

Also, your makefile solution won't work on alternate compilers for windows, as they don't use the ASSS makefile.