# Video conference libification eng discussion, this Thursday 16:30 UTC 2 messages from 2023-04-04 to 2023-04-11. Participants: Emily Shaffer. Thread: https://gitlist.dev/t/59539 ## Emily Shaffer, 2023-04-04 17:14 Subject: Video conference libification eng discussion, this Thursday 16:30 UTC Message-ID: URL: https://gitlist.dev/e/CAJoAoZ%3Dq6ppzErzBT2VygdHbfhezYtFSkM3rLtt%2BgTvdSrLEHQ%40mail.gmail.com ``` Hello folks, Google is hosting a standing engineering discussion about libifying Git, for contributors interested in participating in or hearing about the progress of this effort. Expect this discussion to be free-form and casual - no powerpoints here! We're hoping to hold this meeting every Thursday at 9:30am Pacific (16:30 UTC) via Google Meet. To get an invite to the video conference and the notes document, please reply to this email. Please also add points to the agenda (template follows) if you want to raise awareness of them. I'll reply to this mail tomorrow-ish with the topic we'll discuss during the meeting, and I'll reply again afterwards with the notes. - (asynchronous) What's cooking in libification? - Patches we sent regarding libification - 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.) - Session topic: - Emily ``` ## Emily Shaffer, 2023-04-11 18:39 Subject: Re: Video conference libification eng discussion, this Thursday 16:30 UTC Message-ID: URL: https://gitlist.dev/e/CAJoAoZ%3DFqzODvRQdm9nQtq1wCaFo6sPduWAm2T78%2BMArddH4nA%40mail.gmail.com In-Reply-To: ``` 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@chooglen-macbookpro.roam.corp.google.com - 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 ```