Junio C Hamano <gitster@xxxxxxxxx> writes: > You raised a good point on the issue of external dependencies may > impact Git as a whole, even for those who are not interested in the > particular remote helpers at all. I'll have to think about it. (As I'm sure you know, but starting from the beginning.) There are basically two ways that a program can be built. One is by a user on a particular system. There, checking to see if various libraries are installed and if so enabling some additional feature (that isn't that hard/time-consuming to build) is entirely reasonable. In a packaging system, dependencies are much more troublesome. Dependencies have to be declared, and the build limited to use only those declared dependencies, in order to get repeatable builds and binary packages that can be used on other systems. Dependencies that really are required are fine. But optional dependencies are a problem, because e.g. one doesn't want to require the presence of qt to build something (that isn't already enormous). So if git needs mercurial and subversion installed, plus perhaps 5 other things for less popular remote helpers, that starts to be a real burden. (I realize some packaging systems have a style where the union of the possible dependencies must be present to build, and then the resulting binaries are allocated to split packages. But that's not universal, and it still requires large amounts of unnecessary dependencies to build a package from source.) Ideally, the core of git would have a small set of dependencies, and optional language bindings or remote helpers could be built independently (by running a different build, after git proper was built and installed). It seems more likely that the property of independent builds of optional components will be preserved if the various git-foo pieces are in seaprate trees. But if they are in subdirs of the main git tree, and build by "./configure && make && make install" in the subdir, that's arguably equivalent.
Attachment:
pgpWqcteQDbsS.pgp
Description: PGP signature