Re: [PATCH 2/2] config-parse: split library out of config.[c|h]

"Glen Choo via GitGitGadget" <gitgitgadget@gmail.com> writes:

I think we need to be more careful in how we split. It would be easier if there is a concrete use case, but some preliminary questions:

 - "respect_includes" is in the library, but callers might want to opt
   out of it or provide an alternative way to resolve includes.
 - There is a lot of error reporting capability with respect to the
   source of config, and not all sources are applicable to library
   users. How should we proceed? E.g. should we expect that all library
   users conform to the list here (e.g. even if the source is something
   like but not exactly STDIN, they should pick it), or allow users to
   customize sources?

In the absence of more information, the split I would envision is either something that can only parse a buffer, its error messages being very generic (the caller should turn them into something more specific before showing them to the user) (but one problem here is that we must postprocess includes, which might be a problem if the output of parsing is a flat hashtable, since we wouldn't know which keys are overridden by the includes and which are not); or something that can take in a callback that is invoked whenever something is included and maybe also a callback for access to the object database and that has full knowledge of all sources for error reporting (or allows the caller to customize the sources).