Hi there,
finally I've freed some time to reply very briefly.
" Well I'm quite skeptical of going back to let the config
" parser function to actually parse the arguments, since this
" would not be consistent with the getopt_long function.
I was looking the generated source and I found that if the long_options
structure local to _internal() function would be visible by _configfile()
function, this would solve this problem, because we could easily figure out if
an option accepted/required an argument or not. Moreover, if the option
handling would be implemented via helper functions, there should be no problem
at all.
" Moreover, I'm quite sure that the behavior of the current code is
" actually the same of what would happen if you gave at the
" command line the sequence
"
" --option-with-arg = --arbitrary
"
" i.e., intepret --arbitrary as the argument to --option-with-arg
No, --option-with-arg= (ending in a '=') means an empty(!) option-argument, so
"--arbitrary" will be the next option and not an option-argument.
" if this is not the case, I think the best solution is to
" issue an error saying that in the conf file the line
" "--option-with-arg = " is wrong...
getopt_long() returns OK and empty string (or mabe NULL?) in optarg if no option-argument is found. So the line in question above must remain valid. So, if we find an option at the beginning of the line and a following equal sign, too, it means that user wants to specify an option-argument to this option.
There is an implicit assumpion that each (non-empty and not full-comment) line
in the config file represents one option, and an option declaration must not
exceed the current line where its declaration starts. If no equal sign is found
but option requires/accepts an argument, then this assumption is broken (...
because cmdline_internal() eats the subsequent argv element as option-argument
which is not in the same line as the option's name is in.) We must examine this
assumption first, and if it is correct, we must provide that it will be valid.
No doubt, I think it is quite reasonable. :-))
" I'm not sure I understood the solution of your patch, I mean,
" what does the vector
"
" [0] = PACKAGE_VAR_NAME
" [1] = "--option-with-arg="
" [2] = "arbitrary"
"
" produce?
It will/should produce something like this:
"option (`--option-with-arg') requires an argument."
and that's exactly what I want.