"Glen Choo via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > Begin this process by splitting the config parsing code out of > config.[c|h] and into config-parse.[c|h]. 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).
