From: Emily Shaffer <nasamuffin@google.com>
To: Git List <git@vger.kernel.org>
Subject: Re: Video conference libification eng discussion, this Thursday 16:30 UTC
Date: Tue, 11 Apr 2023 11:39:00 -0700 [thread overview]
Message-ID: <CAJoAoZ=FqzODvRQdm9nQtq1wCaFo6sPduWAm2T78+MArddH4nA@mail.gmail.com> (raw)
In-Reply-To: <CAJoAoZ=q6ppzErzBT2VygdHbfhezYtFSkM3rLtt+gTvdSrLEHQ@mail.gmail.com>
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
next prev parent reply other threads:[~2023-04-11 18:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-04 17:14 Video conference libification eng discussion, this Thursday 16:30 UTC Emily Shaffer
2023-04-11 18:39 ` Emily Shaffer [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-04-11 18:40 Emily Shaffer
2023-04-13 17:00 ` Emily Shaffer
2023-04-25 21:22 Emily Shaffer
2023-05-09 21:08 Emily Shaffer
2023-05-30 21:26 Emily Shaffer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJoAoZ=FqzODvRQdm9nQtq1wCaFo6sPduWAm2T78+MArddH4nA@mail.gmail.com' \
--to=nasamuffin@google.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).