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

From: Junio C Hamano <junkio@cox.net>
Date: Mar 26, 2007, 08:25 UTC
Message-ID: <7v648oza1r.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070326073143.GB44578@codelabs.ru>

Eygene Ryabinkin <rea-git@codelabs.ru> 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.

Show 9 quoted lines

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

Show 5 quoted lines

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