From: Dan Jacques <dnj@google.com>
To: git@vger.kernel.org
Cc: Dan Jacques <dnj@google.com>
Subject: [PATCH 0/1] RUNTIME_PREFIX on POSIX systems.
Date: Thu, 16 Nov 2017 12:05:22 -0500 [thread overview]
Message-ID: <20171116170523.28696-1-dnj@google.com> (raw)
Hello! This would be my first contribution to the Git project, so please
accept my apology in advance for any mistakes and let me know what I can
do better.
This patch expands support for the RUNTIME_PREFIX configuration flag,
currently only used on Windows builds, to include Linux, Darwin, and
FreeBSD. When Git is built with RUNTIME_PREFIX enabled, it resolves its
ancillary paths relative to the runtime location of its executable
rather than hard-coding them at compile-time, allowing a Git
installation to be deployed to a path other than the one in which it
was installed.
It was useful to create Git distribution bundles that could unpack
fully-functional Git deployments to arbitrary locations in support of the
Chromium project. Chromium has been using Git bundles built with a patch
similar to this one on its Linux and Mac continuous integration fleet (plus
some developer systems) for almost a year now.
RUNTIME_PREFIX remains an optional configuration flag, so standard Git
builds will not see any changes. However, with this patch applied,
Linux, Darwin, and FreeBSD users can now optionally use "config.mak" to
enable RUNTIME_PREFIX and build relocatable Git distributions. An
example "config.mak" that builds relocatable Git binaries for Linux/Mac
is:
# BEGIN: config.mak
RUNTIME_PREFIX = YesPlease
gitexecdir = libexec/git-core
template_dir = share/git-core/templates
sysconfdir = etc
# END: config.mak
Implementation notes:
It is unfortunately not straightforward to resolve the full absolute path
of the currently-running binary. On some operating systems, notably
Windows, this path is executively supplied as argv[0]. On other
operating systems, however, argv[0] is supplied by the invoker (shell,
script, kernel, etc.), and is not a reliable source of information about
the running Git binary.
The specific method that this patch employs for binary directory resolution
varies depending on the operating system. On Linux and FreeBSD,
Git resolves "/proc/self/exe" and "/proc/curproc/file" respectively. On
Darwin, Git uses the "_NSGetExecutablePath" function. On all operating
systems, notably Windows, Git continues to fall back to resolution
against argv[0] when it is an absolute path.
When RUNTIME_PREFIX is enabled, the resolved runtime path needs to be
passed to ancillary Git tools for their own resolution requirements:
- C-source Git programs will use the EXEC_PATH_ENVIRONMENT environment
variable that Git already exports, ensuring that any launched tools use
the same runtime prefix as the entry point.
- PERL tooling needs to know how to locate Git's support libraries. When
RUNTIME_PREFIX is configured, Git now exports the GITPERLLIB environment
variable, a mechanism that Git's PERL tooling supports that appears to be
built for testing. PERL scripts installed using MakeMaker incorporate the
builder system's PERL version into their installation path, making
it inconsistent to hard-code; consequently, this patch opts to disable
MakeMaker for RUNTIME_PREFIX builds in order to deterministically control
the destination of Git's support libraries.
- Git also exports the GIT_TEXTDOMAINDIR environment variable when
RUNTIME_PREFIX is set so that its locale configuration can be leveraged
by Git tooling gettext().
Please note that this patch affects Windows Git builds, since the Windows
Git project uses RUNTIME_PREFIX to support arbitrary installation paths.
Notably, PERL scripts are now always installed without MakeMaker (if they
weren't before), and EXEC_PATH_ENVIRONMENT is preferred by tools instead of
re-resolving argv[0]. Chromium uses the stock redistributable Windows Git
package, so I haven't had an opportunity to test this patch on that
platform.
Please take a look and let me know what you think. Thanks!
-Dan
Dan Jacques (1):
exec_cmd: RUNTIME_PREFIX on some POSIX systems
Makefile | 29 ++++++--
builtin/receive-pack.c | 2 +-
cache.h | 2 +
common-main.c | 4 +-
config.mak.uname | 4 ++
exec_cmd.c | 189 +++++++++++++++++++++++++++++++++++++++++++------
exec_cmd.h | 6 +-
gettext.c | 7 +-
git.c | 7 +-
http-backend.c | 2 +-
shell.c | 2 +-
upload-pack.c | 2 +-
12 files changed, 217 insertions(+), 39 deletions(-)
--
2.15.0.448.gf294e3d99a-goog
next reply other threads:[~2017-11-16 17:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 17:05 Dan Jacques [this message]
2017-11-16 17:05 ` [PATCH 1/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems Dan Jacques
2017-11-17 5:08 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171116170523.28696-1-dnj@google.com \
--to=dnj@google.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).