Linus Arver <linusa@xxxxxxxxxx> writes: > It does make me wonder if we should stop being lazy and do the > work that the linker has been doing for us "for free" > ourselves. IOW, stop linking against a monolithic libgit.a. > ... which might help us understand which things need what. Sorry, but I fail see a point in such an exercise. If a tool is available to help us and if there is no downside of using the tool, we should keep using it. If you are proposing to move away from the current build practice because you have a concrete downside of the approach and avoid that, then it might be a good proposal, though. And "we do not learn otherwise" is not a downside of the approach; "we do not learn" comes from your not learning, the tools do not force you to be ignorant. We do not propose to use more __asm__ in our C sources only because compilers were doing that for us "for free" and because the compilers were somehow robbing us the opportunity to learn micro-optimization techniques, do we? A small downside I can immediately think of is possible in a situation where we have been throwing an object file into libgit.a archive that is no longer used by any final executable. In such a scenario, if you change the source file that is compiled into such an unused object file, your next "make" will update libgit.a to replace the unused object file with its new version with your updates, and that would cause the final build product to be linked again with objects needed from libgit.a, but there shouldn't be any change because we are talking about an object that is *not* used by them but still is in libgit.a due to be listed on LIB_OBJS variable. But that is a purely theoretical downside. It may be the case that we haven't done our spring cleaning recently and we haven't noticed that a source file or two are now unused but are still listed on LIB_OBJS to be included in the libgit.a archive. But even if that were the case, it is implausible that you are touching such an unused source file in the first place.
