config-parse: create config parsing library
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 patches 6 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | config: return positive from git_config_parse_key()builtin/ config.c config.h +2 more | +28 | 4 replies | |
| 2/2 | config-parse: split library out of config.[c|h]Makefile config-parse.c config-parse.h +2 more | +795 | 2 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] config-parse: create config parsing library
Config parsing no longer uses global state as of gc/config-context, so the natural next step for libification is to turn that into its own library. This series starts that process by moving config parsing into config-parse.[c|h] so that other programs can include this functionality without pulling in all of config.[c|h].
To use config-parse.[c|h], an external caller has to obey our convention of using "#include git-compat-util.h" at the start of the .c file. This is doable by including the in-tree git-compat-util.h and linking against the libgit.a Make target (which is admittedly cumbersome), and we've verified this by compiling and linking to the library using the Google-internal version of Bazel.
This series is not meant to distract from Calvin's git-std-lib series [1]. In fact, the two are complementary: git-std-lib will make it possible for external callers to compile a smaller subset of files in order to use a library. Doing this for config-parse will make config-parse easier to use, while testing that git-std-lib does what we want it to.
I considered calling the library config-ll (like we do in other parts of the codebase) instead of config-parse, with the intention of adding more "low level" config code to it in the future. A benefit to that is that by having fewer modules, dependency management is easier to reason about. However, I struggled to think of what other config code could be considered "low level" but doesn't make sense as its own module. (E.g. struct config_set is a low level implementation detail, but I think it's well-scoped enough to be its own config-set module.) I'd appreciate suggestions on how the config libraries could be organized.
[1]
https://lore.kernel.org/git/[email protected]/
Glen Choo (2):
config: return positive from git_config_parse_key()
config-parse: split library out of config.[c|h]
Makefile | 1 + builtin/config.c | 3 +- config-parse.c | 611 +++++++++++++++++++++++++++++++++++++++++++ config-parse.h | 182 +++++++++++++ config.c | 636 +-------------------------------------------- config.h | 146 +---------- submodule-config.c | 4 +- t/t1300-config.sh | 16 ++ 8 files changed, 816 insertions(+), 783 deletions(-) create mode 100644 config-parse.c create mode 100644 config-parse.h
base-commit: aa9166bcc0ba654fc21f198a30647ec087f733ed
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1551%2Fchooglen%2Fconfig%2Fparse-lib-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1551/chooglen/config/parse-lib-v1
Pull-Request: https://github.com/git/git/pull/1551
Signature · 1 line
gitgitgadget