From: Dan Jacques <dnj@google.com>
To: avarab@gmail.com
Cc: Johannes.Schindelin@gmx.de, dnj@google.com, git@vger.kernel.org,
gitster@pobox.com
Subject: Re [PATCH 1/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems
Date: Mon, 20 Nov 2017 21:41:02 -0500 [thread overview]
Message-ID: <20171121024102.14153-1-dnj@google.com> (raw)
In-Reply-To: <87k1ykwrfv.fsf@evledraar.booking.com>
Ævar Arnfjörð Bjarmason @ 2017-11-20 21:50 UTC suggested:
> So LeonT over at #p5p helped me with this. He believes this'll work
> (unless MakeMaker INSTALL_BASE is set, but that should break the Git
> install anyway):
I think that the problem with this approach is that it uses the local
"Config" module. The primary purpose of RUNTIME_PREFIX(_PERL) is that one
can build/install Git into a directory, then either move that directory
somewhere else or archive it and put it on a different (binary-compatible)
system altogether.
The latter case concerns me here. If the "Config" module is loading local
system paths, then the relative pathing between "$Config{installsitelib}"
and "$Config{siteprefixexp}" may not be consistent between systems, so an
archive built from one system may not have a compatible relative
directory structure when resolved with the Config module on another
system.
Since we control the installation process and paths, we know that the
directory structure looks someting like:
.../prefix/$GITEXECDIR/git-perl-script
.../prefix/$RELPERLPATH/Git.pm
Our goal is to, given the directory that "git-perl-script" belongs to,
first identify the path for ".../prefix" and then append "$RELPERLPATH" to
it to generate the full library path.
The most straightforward way to do this, to me, is to:
1) Have the Makefile hard-code "$RELPERLPATH" and "$GITEXECDIR" (relative
paths) into the header code.
2) Assert that "$FindBin::Bin" (the directory containing the script) ends
with "$GITEXECDIR".
3) Remove "$GITEXECDIR" from the end of "$FindBin::Bin" to obtain
".../prefix" ($prefix). Simple string truncation is probably fine for
this.
4) Add "File::Spec->catdir($prefix, $RELPERLPATH)" to "lib".
I don't think path separators are a problem, since the Makefile uses "/"
indiscriminately. Even Git-for-Windows seems to run its PERL scripts in
a POSIX environment (mingw).
Does this sound like a reasonable way to proceed?
next prev parent reply other threads:[~2017-11-21 2:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-19 17:31 [PATCH v2 0/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems Dan Jacques
2017-11-19 17:31 ` [PATCH 1/1] " Dan Jacques
2017-11-20 1:01 ` Junio C Hamano
2017-11-20 21:00 ` Ævar Arnfjörð Bjarmason
2017-11-20 21:50 ` Ævar Arnfjörð Bjarmason
2017-11-21 2:41 ` Dan Jacques [this message]
2017-11-22 12:09 ` Re " Ævar Arnfjörð Bjarmason
2017-11-22 14:27 ` Dan Jacques
2017-11-20 21:58 ` Re(2): " Dan Jacques
2017-11-20 22:46 ` Ævar Arnfjörð Bjarmason
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=20171121024102.14153-1-dnj@google.com \
--to=dnj@google.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).