Taylor Blau <me@xxxxxxxxxxxx> writes: > But I am not sure that I agree that this series is moving us in the > right direction necessarily. Or at least I am not convinced that > shipping the intermediate state is worth doing before we have callers > that could drop '#include "config.h"' for just the parser. > > This feels like churn that does not yield a tangible pay-off, at least > in the sense that the refactoring and code movement delivers us > something that we can substantively use today. > > I dunno. > > Thanks, > Taylor Thanks for calling this out. We do want our changes to be good for both the libification and the non-libification cases as much as possible. As it is, I do agree that since we won't have callers that can use the new parser header (I think the likeliest cause of having such a caller is if we have a "interpret-config" command, like "interpret-trailers"), we probably shouldn't merge this (at least, the last 2 patches). I think patches 1-3 are still usable (they make some internals of config parsing less confusing) but I'm also OK if we hold off on them until we find a compelling use case that motivates refactoring on the config parser.
