Eygene Ryabinkin <rea-git@xxxxxxxxxxx> writes: >> Maybe later you might even want to view the graphical history >> from the server displaying on remote X, who knows? > > Not sure: I don't like X on the servers ;)) But others can... Did you know that you can have only minimum X clients on your server machine, and display on remote X terminals? But that is besides the point. >> We have NO_CURL and such because lack of the necessary libraries >> and headers prevent your build from completing, but in the case >> of git-gui and gitk, they are just scripts and you would not >> have any trouble in building. I do not know if adding more >> conditional to Makefile in order to skip them is worth it. > > OK, I reworked the patch following the suggestion of Jakub and Johannes: > now configure has the built-in detection of the Tcl/Tk binary and has > the --with-tcltk/--without-tcltk options. That is exactly what I am quite against. I often find other people's packages silly when they disable tk support only because the build procedure does not find tcl/tk installed on the system it is built on, even when the tk component of the package is pure wish script and does not have any C native stuff (which requires libtcl development component on the build system, which in turn justifies such disabling). > And regarding the building troubles and the additional knob in the > Makefile: the trouble is in the packaging process. For example, RPM > or FreeBSD ports are looking at what is really installed, so if > user do not want the Tcl/Tk part, then no package parts that depend > on it should be installed. I think the simple RPM spec file we ship with git.git takes care of that nicely by splitting gitk into a separate package (As it was Chris Wright's work, I cannot take credit for that part at all). I would imagine both modern distro's packaging system and people who actually maintain packages for distros are capable enough to handle this situation just fine. I still do not think the "packaging difficulty" is not a strong enough reason. But I could be persuaded otherwise... - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html