[TOPIC 3/12] Designing a Makefile for multiple libraries

[Taylor Blau <me@ttaylorr.com>]

(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
     libraries
* 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
  builds...
* (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
     error?
   * (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
     memory