The notes from this session follow: - (asynchronous) What's cooking in libification? - Patches we sent regarding libification - How to review coccinelle? https://lore.kernel.org/git/kl6l7cuycd3n.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx - Patches for review related to the libification effort - (asynchronous) What happened in the past 1-2 weeks that interested parties or intermittent contributors need to know? - (asynchronous) Where are you stuck? What eng discussions do we want to have? (We'll choose a topic from this list a day ahead of the meeting.) * Emily: what's the least ugly way to move existing code into "libified" code? oldname\_lib.[ch] in the top level? lib/oldname.[ch]? lib/oldname/oldname.[ch]? Something else? * Emily/Calvin: How do we feel about https://github.com/rra/c-tap-harness/ ? (3) * Calvin: Git-compat-util contains many necessary includes, macros, and inline functions used across all of git, so therefore any library must include it. There are a couple of dependencies inside of it, however, that prevent libraries from compiling independently with it. (lots) - Session topic: git-compat-util * Intros * Emily: TL git-core @ google * Jonathan: git-core @ google * Calvin: git-core @ google * Randall: Platform maintainer for NonStop * Cem: Interested in contributing to Git but haven't sent anything yet, hi 🙂 Curious to hear what's going on and hoping to help * Siddharth: visiting git-core for just Q2 (@ google) * Linus: 20%ing on git-core (@ google) - interested in libification stuff * Glen: git-core @ google * Randall: Mostly concerned about licensing and whether libification will change the licensing stuff * Emily: for now Google doesn't see a reason to try to relicense anything * Calvin: Git-compat-util contains many necessary includes, macros, and inline functions used across all of git, so therefore any library must include it. There are a couple of dependencies inside of it, however, that prevent libraries from compiling independently with it. * Everything includes git-compat-util.h. So we need git-compat-util.h to either be not a catchall (like we did with cache.h), and should we libify git-compat-util dependencies? * There are some things that are explicitly compatibility related, like git\_pread(). This is ifdef'd so we always have a pread implementation. That implementation comes from wrapper.h, and wrapper.h/wrapper.c includes Lots Of Stuff :') including trace2 and usage * die() impl is pretty bad also * Jonathan: We could say that git-compat-util.h can't depend on anything else. For example, we can't die(). This might be good, because anything provided by the platform shouldn't be die()ing * Calvin: So that means we don't even want to define usage(), die(), warn(), error() in git-compat-util.h. That kind of makes sense! But some libraries want to use die() for now * Emily: yeah, but we need to refactor that out 🙂 * Calvin: Probably that means we should figure out the error returning design * Linus: Are there already circular dependencies here? * Emily: Does that mean we should build all the everyone-needs-it libraries into one binary, so they can depend on each other in a complicated way if they need to? * Calvin: That doesn't really help with trace2 dependency * Randall: Are we sure how the packaging is gonna happen? Is it static, dynamic, …? * Emily: Within Git codebase, not really that worried yet beyond making sure they CAN compile independently and unit test * Jonathan: So mostly focusing on "can I compile this explicit subset of .[ch] files and run unit tests on them" * Randall: Similar experience with OpenSSL and they dll-ified their code. That had a lot of platform-specific pain. Please tell me if you're interested in dlls 🙂 * Emily: As far as the trace2 stuff, I imagine most people calling Git libraries from their code won't want to trace at all. So we probably want to libify trace2 stuff \*and\* provide a stubbed version of the API, since that's such a common use case * Calvin: Maybe it makes sense to build that tr2-noop lib right into a large "git-common-lib" * Calvin: and we can put strbuf, string\_list, hashmap, etc. in there and we might even be able to leave some things stubbed in git\_compat\_util.h…. * Calvin: This combined with packaging everything together into a common library actually sounds really appealing * Glen: Do we have a good idea of what everything that would be included into this common library is? How can we annotate what is and isn't part of it? * Randall: A lot of platform problems we have had in the past are coming from git-compat-util. I'm always worried about it, please be careful with it 🙂 * Calvin: Hoping to avoid touching anything that's got an #ifdef as a general rule * Randall: the atexit() code is a place to be careful for sure. And NonStop is trying to start using pthreads. So, yes, I'm very worried here. * Linus: Would it make sense to have some large "standard library" file with no deps and start moving stuff into it? * Emily: I'm worried about that turning into a mega-header like cache.h (or git-compat-util.h) * Randall: I like cleaner containment than making things extremely broad
