summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 651fbba)
raw | patch | inline | side by side (parent: 651fbba)
author | Shawn O. Pearce <spearce@spearce.org> | |
Fri, 22 Feb 2008 00:27:46 +0000 (19:27 -0500) | ||
committer | Shawn O. Pearce <spearce@spearce.org> | |
Fri, 22 Feb 2008 06:38:32 +0000 (01:38 -0500) |
When we are being built by the Cygwin package maintainers we need to
embed the POSIX path to our library files and not the Windows path.
Embedding the Windows path means all end-users who install our Cygwin
package would be required to install Cygwin at the same Windows path
as the package maintainer had Cygwin installed to. This requirement
is simply not user-friendly and may be infeasible for a large number
of our users.
We now try to auto-detect if the Tcl/Tk binary we will use at runtime
is capable of translating POSIX paths into Windows paths the same way
that cygpath does the translations. If the Tcl/Tk binary gives us the
same results then it understands the Cygwin path translation process
and should be able to read our library files from a POSIX path name.
If it does not give us the same answer as cygpath then the Tcl/Tk
binary might actually be a native Win32 build (one that is not
linked against Cygwin) and thus requires the native Windows path
to our library files. We can assume this is not a Cygwin package
as the Cygwin maintainers do not currently ship a pure Win32 build
of Tcl/Tk.
Reported on the git mailing list by Jurko Gospodnetić.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
embed the POSIX path to our library files and not the Windows path.
Embedding the Windows path means all end-users who install our Cygwin
package would be required to install Cygwin at the same Windows path
as the package maintainer had Cygwin installed to. This requirement
is simply not user-friendly and may be infeasible for a large number
of our users.
We now try to auto-detect if the Tcl/Tk binary we will use at runtime
is capable of translating POSIX paths into Windows paths the same way
that cygpath does the translations. If the Tcl/Tk binary gives us the
same results then it understands the Cygwin path translation process
and should be able to read our library files from a POSIX path name.
If it does not give us the same answer as cygpath then the Tcl/Tk
binary might actually be a native Win32 build (one that is not
linked against Cygwin) and thus requires the native Windows path
to our library files. We can assume this is not a Cygwin package
as the Cygwin maintainers do not currently ship a pure Win32 build
of Tcl/Tk.
Reported on the git mailing list by Jurko Gospodnetić.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Makefile | patch | blob | history |
diff --git a/Makefile b/Makefile
index 1ba0e788f9a99980b4ab3a35f213f0a4ffcbaa1e..01e0a46ba56faa8a17ed8710346b18dd215899c7 100644 (file)
--- a/Makefile
+++ b/Makefile
ifeq ($(uname_O),Cygwin)
GITGUI_SCRIPT := `cygpath --windows --absolute "$(GITGUI_SCRIPT)"`
- gg_libdir_sed_in := $(shell cygpath --windows --absolute "$(gg_libdir)")
+
+ # Is this a Cygwin Tcl/Tk binary? If so it knows how to do
+ # POSIX path translation just like cygpath does and we must
+ # keep libdir in POSIX format so Cygwin packages of git-gui
+ # work no matter where the user installs them.
+ #
+ ifeq ($(shell echo 'puts [file normalize /]' | '$(TCL_PATH_SQ)'),$(shell cygpath --mixed --absolute /))
+ gg_libdir_sed_in := $(gg_libdir)
+ else
+ gg_libdir_sed_in := $(shell cygpath --windows --absolute "$(gg_libdir)")
+ endif
else
ifeq ($(exedir),$(gg_libdir))
GITGUI_RELATIVE := 1