Remove cfg macro expansion from the docs

Issue #30 resolved
Former user created an issue

Copied from bug number 92 in old bug database.

numpf: I'm pretty sure I saw in the docs it said you could define macros what would be expanded, in addition to using them for #if(n)def. Unless I'm completely missing something, src/main/app.c doesn't do this and my tests bear this out. Either the docs or code, depending on intent, should be fixed as necessary.

grelminar: it was removed in rev 531775113616300e82d8e4f9c27663c373571494 because the enum stuff seemed like a better idea. i vote for removing it from docs, unless you can think of a good use for it.

numpf: conf/svs/svs.conf uses #include to create a ship settings heirarchy. svs-std-ship is the base. I wanted to be able to be able to define a $STDSHIP macro and use it in place of those includes, so I could change the base for all ships at once.

I can likely imagine other uses for symbolic programming in config files. Then again, I can imagine tasks that require runtime config objects. As I may have said elsewhere, I think cfg system should be redone.

grelminar: What is a "runtime config object" and what can you do with one?

I guess I can imagine a few uses for macros, but there are probably other ways to achieve the same results. I wouldn't object to re-adding them.

What I'd really like to do to config is to write a proper lexer and parser, and then have dirty values be written back to where they came from.

numpf: cfg overhaul will be discussed later and elsewhere.

For now I agree to just strip the doc, which is the comment at the top of app.c:

  • macros are not expanded automatically. use $macro, $(macro), or
  • ${macro} to get their values. macro names are case-insensitive.
  • macros can't take arguments.

Looks like all of that should be removed.

Comments (1)

  1. Log in to comment