Re: [PATCH] Added make options NO_GUI and WITH_P4IMPORT.

Eygene Ryabinkin [off-list ref] writes:

quoted

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.

quoted

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...