(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
