About GIT_EXEC_PATH
Johannes Sixt
anymore out of the box. The reason is that I introduced a function
builtin_exec_path() that computes the path from the program invocation and
ignores the predefined GIT_EXEC_PATH (which is the value of $(gitexecdir) int
the Makefile).
The intent of the function is to have a relocatable binary that does not use
absolute compiled-in paths. For this purpose, DEFAULT_GIT_TEMPLATE_DIR and
ETC_GITCONFIG are defined as relative paths that are interpreted as relative
to git_exec_path() (which itself depends on GIT_EXEC_PATH unless overridden
via environment or program option).
The trivial way out is, of course, to define gitexecdir = $(bindir) in the
Makefile. This will have an effect *only* on how the programs are installed,
but will leave the internals unchanged.
But what do we really want?
- Does it make sense to derive builtin_exec_path() from the git.exe invocation
(the status quo)?
- What should the other paths be relative to? git_exec_path() or git.exe?
I think the latter makes more sense. It allows to have git.exe anywhere by
setting GIT_EXEC_PATH environment to the installation location. The default
of git_exec_path() would be relative to git.exe.
-- Hannes
Marius Storm-Olsen
> The intent of the function is to have a relocatable binary that does not use
> absolute compiled-in paths. For this purpose, DEFAULT_GIT_TEMPLATE_DIR and
> ETC_GITCONFIG are defined as relative paths that are interpreted as relative
> to git_exec_path() (which itself depends on GIT_EXEC_PATH unless overridden
> via environment or program option).
>
> The trivial way out is, of course, to define gitexecdir = $(bindir) in the
> Makefile. This will have an effect *only* on how the programs are installed,
> but will leave the internals unchanged.
>
> But what do we really want?
Now, reading this I wonder if really it should be something different.
The ETC_GITCONFIG and DEFAULT_GIT_TEMPLATE_DIR are really pointing to
configurations which affect all users, right? Shouldn't they then be
located under the "All Users"/"Default User" directory? Normally under
"C:\Documents and Settings\All Users\Application Data", but retrievable by
SHGetSpecialFolderPath(0, pszPath, CSIDL_COMMON_APPDATA, 0);
Folder description:
"This folder should be used for application data that is not user
specific. For example, an application may store a spell check
dictionary, a database of clip-art or a log file in the
CSIDL_COMMON_APPDATA folder. This information will not roam and is
available to anyone using the computer. By default, this location is
read-only for normal (non-admin, non-power) Users."
Just a brief thought..
--
.marius
Johannes Schindelin
On Mon, 7 Jul 2008, Marius Storm-Olsen wrote:
> Johannes Sixt said the following on 07.07.2008 21:11:
> > The intent of the function is to have a relocatable binary that does
> > not use absolute compiled-in paths. For this purpose,
> > DEFAULT_GIT_TEMPLATE_DIR and ETC_GITCONFIG are defined as relative
> > paths that are interpreted as relative to git_exec_path() (which
> > itself depends on GIT_EXEC_PATH unless overridden via environment or
> > program option).
> >
> > The trivial way out is, of course, to define gitexecdir = $(bindir) in
> > the Makefile. This will have an effect *only* on how the programs are
> > installed, but will leave the internals unchanged.
> >
> > But what do we really want?
>
> Now, reading this I wonder if really it should be something different. The
> ETC_GITCONFIG and DEFAULT_GIT_TEMPLATE_DIR are really pointing to
> configurations which affect all users, right?
Almost right: they affect all users that happen to call Git _there_.
> Shouldn't they then be located under the "All Users"/"Default User"
> directory? Normally under "C:\Documents and Settings\All
> Users\Application Data", but retrievable by
> SHGetSpecialFolderPath(0, pszPath, CSIDL_COMMON_APPDATA, 0);
No, because that would affect all msysGit installations.
Ciao,
Dscho
Johannes Schindelin
On Mon, 7 Jul 2008, Johannes Sixt wrote:
> Since the 'dash-less' changes are now in upstream, mingw.git does not
> work anymore out of the box. The reason is that I introduced a function
> builtin_exec_path() that computes the path from the program invocation
> and ignores the predefined GIT_EXEC_PATH (which is the value of
> $(gitexecdir) int the Makefile).
What prevents you from stripping "/bin/<basename>.exe" or
"/libexec/git-core/<basename>.exe", whichever was found, from the path?
Ciao,
Dscho
Johannes Sixt
> Now, reading this I wonder if really it should be something different.
> The ETC_GITCONFIG and DEFAULT_GIT_TEMPLATE_DIR are really pointing to
> configurations which affect all users, right? Shouldn't they then be
> located under the "All Users"/"Default User" directory? Normally under
> "C:\Documents and Settings\All Users\Application Data", but retrievable by
> SHGetSpecialFolderPath(0, pszPath, CSIDL_COMMON_APPDATA, 0);
>
> Folder description:
> "This folder should be used for application data that is not user
> specific. For example, an application may store a spell check
> dictionary, a database of clip-art or a log file in the
> CSIDL_COMMON_APPDATA folder. This information will not roam and is
> available to anyone using the computer. By default, this location is
> read-only for normal (non-admin, non-power) Users."
How is this directory any different from the installation location of a
program (C:\Program Files\...), I wonder? I see no need to use this Win32
specific API.
-- Hannes
Johannes Sixt
And use the result as the base to look for templates and ETC_GITCONFIG? What
if neither matches?
-- Hannes
Johannes Schindelin
Well, what do you do at the moment? Let's use that as a fallback, no? (I
assume that you just strip the last path element.)
Ciao,
Dscho
Johannes Sixt
A picture is in order, I think.
We could derive directories like this:
[*] [+]
(1) git.exe -----> exec-path -----> templates
|\----> etc/gitconfig
\----> html docs
or we could do it like this:
[*]
(2) git.exe ------> exec-path
| [+]
|\-----> templates
|\-----> etc/gitconfig
\-----> html docs
[*] can be overridden with --exec-path option or GIT_EXEC_PATH env var
[+} can be overridden with --template option GIT_TEMPLATE_DIR env var
Which one is more appropriate?
-- Hannes
Johannes Schindelin
IMHO 2), since the templates directory and the exec-path directory are
same in nature: they are directories with additional stuff.
Ciao,
Dscho
Johannes Sixt
With (1) you could install git.exe (or even a symlink to git on Unix)
somewhere in $PATH, and the rest in $anywhere and just point GIT_EXEC_PATH
(and only that) to $anywhere/libexec/git-core. Would you think that this
feature is not worth it?
-- Hannes
Johannes Schindelin
Correct. I think this feature is not worth it. I think all of Git should
be installed in one place, on Windows.
Ciao,
Dscho
Johannes Sixt
OK, I'll take that route then. It's easier to implement, I think, and the
default settings are less cryptic: all of them are relative to $(bindir); in
version (1) $(gitexecdir) would be relative to $(bindir), and the others
relative to $(gitexecdir).
-- Hannes
Johannes Schindelin
Heh, sometimes simpler really is better :-)
Ciao,
Dscho
Steffen Prohaska
I've been offline the last couple of days.
I'll send patches related to htmldir that might conflict with your
planned
changes. If you haven't yet started you could have a look on the patch
that introduces system_path() before you start.
Steffen