On 2023.10.24 15:50, Jonathan Tan wrote: > 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. Thanks everyone for the revived discussion here. I think I agree, this series is not going in the right direction. Additionally, our internal use case for this change has evaporated, so let's just drop the series. We can pick it up again later if interest returns.
