steadmon@xxxxxxxxxx writes: > It is convenient to have common_exit() in its own object file so that > standalone programs may link to it (and any other object files that > depend on it) while still having their own independent main() function. I am not so sure if this is a good direction to go in, though. The common_exit() function does two things that are very specific to and dependent on what Git runtime has supposed to have done, like initializing trace2 subsystem and linking with usage.c to make bug_called_must_BUG exist. I understand that a third-party or standalone non-Git programs may want to do _more_ than what our main() does when starting up, but it should be doable if make our main() call out to a hook function, whose definition in Git is a no-op, that can be replaced by their own implementation to do whatever they want to happen in main(), no? The reason why I am not comfortable with this patch is because I cannot say why this split is better than other possible split. For example, we could instead split only our 'main' out to a separate file, say "main.c", and put main.o together with common-main.o to libgit.a to be found by the linker, and that arrangement will also help your "standalone programs" having their own main() function. Now with these two possible ways to split (and there may be other split that may be even more convenient; I simply do not know), which one is better, and what's the argument for each approach? > So let's move it to a new common-exit.c file and update the Makefile > accordingly. > > Change-Id: I41b90059eb9031f40c9f65374b4b047e7ba3aac0 > --- > Makefile | 1 + > common-exit.c | 26 ++++++++++++++++++++++++++ > common-main.c | 24 ------------------------ > 3 files changed, 27 insertions(+), 24 deletions(-)
