Re: [PATCH] Add --with-tcltk and --without-tcltk to configure.

From: Eygene Ryabinkin <rea-git@codelabs.ru>
Date: Mar 29, 2007, 08:29 UTC
Message-ID: <20070329082908.GH59098@codelabs.ru>
In-Reply-To: <7vwt107a3g.fsf@assigned-by-dhcp.cox.net>

Junio, Thu, Mar 29, 2007 at 01:00:35AM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> Actually, look at the wish script you are running sed on.
> 
> 	exec wish "$0" -- "$@"
> 
> If you substitute "wish" with "/i use stupid/$PATH/to/wish", I
> think Tcl splits the path at SP and does not protect $var
> reference, so the careful quoting in the Makefile is still not
> good enough ;-).

It is not Tcl/Tk, who interprets that string: it is for shell. So, if the line will look like exec "/insane path/to/wish" "$0" -- "$@", then we will just get the "/insane path/to/wish" executed with the script name on the first place and other arguments following the '--'.

Or you meant something different? I am little confused with the '$PATH' in your example. Was it intended?

Show 10 quoted lines

> But come to think of it, it lets shell handle $PATH to find wish
> anyway, so *unless* we have specific version dependency to wish
> that wish binary normally found on user's $PATH is inadequate,
> we probably should not even need to be doing any of this path
> munging.  You might end up discovering the path to wish binary
> in your autoconf script, we do not have to use it.  ./configure
> can just see if there is wish, and set NO_TCLTK appropriately
> without any of the path business.
> 
> What do you think?

There are problems at least with FreeBSD: it just installs the wish8.4, wish8.3, wish8.2, etc. It does not provide the bare 'wish' as the link to one of those: it is hard to tell what 'wish' we will like to use. Sure, I can search for 'wish8.3', 'wish8.4' in the configure script. But when new wish will be out the Git configure should be fixed for it. Seems like passing the path of the Tcl/Tk interpreter still have some meaning in this situation.

Show 12 quoted lines

> 
> > By the way, when I was creating the git.spec from the git.spec.in,
> > I had the 'Version' field equal to the '1.5.1-rc1.GIT' and RPM
> > does not like the '-' characters inside the versions.
> 
> That is semi-intended, in that you are not even supposed to be
> building with "1.5.1-rc1.GIT".  The version file in the tarball
> that git.spec file lives in should use git-describe, built from
> the source before the tarball was made, to get the version
> number, and wouldn't be "$anything.GIT", which is the last-ditch
> fallback string, which is set by GIT-VERSION-GEN for people who
> build in a wrong way.

Just built the tarball and tried the produced specfile: it wanted to build 'git-1.5.1.rc1.26.g7a88-dirty'. Yes, my repository was dirty, I admit it. Maybe you're right and there is no good reason for the '-' symbols in the version string.

-- 
Eygene