mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <>
Subject: [TOPIC 3/12] Designing a Makefile for multiple libraries
Date: Mon, 2 Oct 2023 11:18:46 -0400	[thread overview]
Message-ID: <ZRrfVtIbYrPiY3qy@nand.local> (raw)
In-Reply-To: <ZRregi3JJXFs4Msb@nand.local>

(Presenter: Calvin Wan, Notetaker: Keanen Wold)

* Looking for help with makefile use and how he's making libraries
* Wants to have rules to leverage makefiles repeatable for future libraries
* Wants a fail fast for breaking libraries
* Current approach that isn't working so well
   * Each library to have its own section - using directives to section off the
* Request
   * Are there makefile experts who can help?
* (Jonathan) do you have an example?
   * (Calvin) using ‘ifdef GIT_STD_LIBRARY' to tweak what goes in LIB_OBJS. This
     approach doesn't scale.
* (Peff) for every C file you have two copies?
   * No, for every reference they are using the same file
* (Junio) libgit.a will we need something different, if so, why?
   * Stubs, how do they come into play?
   * If we had a makefile for a library, we're trying to understand how we have a subset
* (Jonathan) Do I end up with two different .o files?
   * Yes, there is a subset of shared and not shared files
   * Some of the objects are the same, the stubs are different.
   * The problems are the stubs which are shared
* (Calvin?) ideally we want the .o files to be the same
   * Yes
* (Peff) if you are worried about writing the same rules again and again, there
  should be a solution
   * Yes, it will likely have to be a custom pattern
   * Does anyone have a solution that has worked before? A simple solution? OR
     our own custom templating
* (Phillip) can we build the file in standard git so we're not creating the file
  for two different libraries?
* (Emily) if we are changing the behavior using standard git builds and library
* (Jonathan) in the past other projects used recursive "make" to reflect module
  structure in the build structure, which has lots of downsides (Peter Miller,
  Recursive make considered harmful).
   * We can define our own structure of what we want the Makefile to look like.
     Linux kernel files are perhaps a good example. There's not necessarily one
     standard everyone follows, it tends to be very codebase specific
   * For better or worse, "make" is a "build your own" kind of build system
* (Emily) why are we not using a different build system? Such as CMake
   * What are the technical reasons for make?
* (Junio) How do the libraries and make relate to each other? Avoiding
  compile-time conditional behavior seems desirable anyway - git as a consumer
  of the library can also benefit from cleaner error handling.
   * (Emily) cleanup related to the library might mean moving exit()/die()
     closer to the built-in. Do we consider that potentially valuable instead of
     useless churn?
      * (Junio) yes
* (Jakub) It's easier to die when something is wrong at the top level
   * (Peff) It depends on what level of error handling we want to get to. The
     reality of C is every single malloc can fail. Do we need to check every
   * (brian) standard error handling mechanism would be helpful.
* (Emily) for libgit2 does the caller handle the memory?
   * (brian) a dummy value (git_buf_oom) where you can check if it's out of

  parent reply	other threads:[~2023-10-02 15:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-02 15:15 Notes from the Git Contributor's Summit, 2023 Taylor Blau
2023-10-02 15:17 ` [TOPIC 0/12] Welcome / Conservancy Update Taylor Blau
2023-10-02 15:17 ` [TOPIC 1/12] Next-gen reference backends Taylor Blau
2023-10-02 15:18 ` [TOPIC 02/12] Libification Goals and Progress Taylor Blau
2023-10-02 15:18 ` Taylor Blau [this message]
2023-10-02 15:19 ` [TOPIC 4/12] Scaling Git from a forge's perspective Taylor Blau
2023-10-02 15:19 ` [TOPIC 5/12] Replacing Git LFS using multiple promisor remotes Taylor Blau
2023-10-02 15:20 ` [TOPIC 6/12] Clarifying backwards compatibility and when we break it Taylor Blau
2023-10-02 15:21 ` [TOPIC 7/12] Authentication to new hosts without setup Taylor Blau
2023-10-02 15:21 ` [TOPIC 8/12] Update on jj, including at Google Taylor Blau
2023-10-02 15:21 ` [TOPIC 9/12] Code churn and cleanups Taylor Blau
2023-10-02 15:22 ` [TOPIC 10/12] Project management practices Taylor Blau
2023-10-02 15:22 ` [TOPIC 11/12] Improving new contributor on-boarding Taylor Blau
2023-10-02 15:22 ` [TOPIC 12/12] Overflow discussion Taylor Blau

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZRrfVtIbYrPiY3qy@nand.local \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

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).