> I don't think the (main) concern of the 'keep cfg' camp is that the syntax is
> different between --hint[LineTooLong]=off (cfg) ...
That was not my proposal, the `--` prefix is not required in cfg syntax.
> So I don't think we need to go out of our way to reverse engineer a type
> system that would give a meaning to what is originally a command line syntax
> hint[LineTooLong]=off, clang.cpp.options.linker etc.
IMHO making things checkable by the compiler is worth the effort most of the
time, but that's just an opinion. Btw., many (all?) hints, warnings and errors
already have enums defined for them.
> If anything, it'd be better to provide a helper macro or helper proc that
> parses these from a string, usable in config.nims
Yes, it could be done with a macro. Much nicer than string parsing:
cfg:
hint[LineTooLong]=off
clang.cpp.options.linker="-Oz -s ASM_JS=1 --separate-asm"
Run
Again, without the \--. The double dashes are less typing in a nims script than
switch, but they have disadvantages: they introduce a UNIX/GNU specific
convention into the config syntax of a multi-platform language and they work
for config options which aren't even command line arguments.
> \--foo.bar syntax is un-constrained (see
> [https://github.com/nim-lang/Nim/pull/8757#issuecomment-417781883](https://github.com/nim-lang/Nim/pull/8757#issuecomment-417781883))
> so it's impossible to map a type hierarchy to it.
Looks like a good point (without understanding the details). So it would be
major changes to the config system or something like the `config` block above,
I guess. Also solves your second point.
> also not sure about how you'd map this: define:SYMBOL:VAL
It can be parsed (says `dumpTree`), so there's no problem if `define` is a
macro.
