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

[Eygene Ryabinkin <rea-git@codelabs.ru>]

Junio,
Thu, Mar 29, 2007 at 01:00:35AM -0700, Junio C Hamano wrote:
> 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?

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

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