Re: Video conference libification eng discussion, this Thursday 16:30 UTC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux