mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Dan Jacques <>
Subject: Re: [PATCH v4 0/4] RUNTIME_PREFIX relocatable Git
Date: Wed, 29 Nov 2017 17:38:07 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> In general this whole thing structurally looks good to me with the
> caveats noted in other review E-Mails.
> I haven't done anything but skim the details of the "where's my
> executable" C code though, just looked at what it's doing structurally.
> I think it makes sense for this to land first ahead of my patch. This is
> an actual feature you need, whereas I just hate our use of MakeMaker,
> but that can wait, unless you're keen to rebase this on my patch. Would
> probably make your whole diff a bit shorter.

I'm not strictly pressed for time here, so we can put this off if that's
strategically appropriate. Chromiuum, right now, just manually patches
upstream Git with a similar patch set, so it's working and function. This
is just an effort to upstream those changes for everyone else to enjoy!

I think that landing in either order is probably okay, so if your RFC
goes through pretty quickly I don't mind rebasing, but if this is otherwise
good to go in v5, I wouldn't mind landing it and then removing the
obsoleted parts during the Makefile update.

> The whole converting our absolute to relative paths in the make code is
> unavoidably ugly, but after having an initial knee-jerk reaction to it I
> don't see how it can be avoided. I was hoping most of these paths
> could/would just be a fixed path away from our libexec path, but alas
> due to having had these configurable all along that simplicity seems out
> of reach.

Yeah I spent no small amount of time massaging that code hoping some better
formulation would shake out, and this is what I ended up with.
UNTIME_PREFIX_PERL is a specialty build with a stronger set of assumptions
than the standard installation (RE prefix-relative paths).

> Maybe I asked this before, but I don't see any obvious reason for why
> RUNTIME_PREFIX_PERL is a different thing than RUNTIME_PREFIX as opposed
> to us just doing the right thing for the perl scripts.

I did this to isolate Windows builds from the Perl script changes. Git-for-
Windows uses (invented) RUNTIME_PREFIX, but runs its Perl scripts in a
MinGW sub-environment which, internally, has the Perl libraries installed
at a fixed path, so it doesn't need any special resolution logic.

I support that if Git-for-Windows wants to, a trivial future patch can
merge the two, so I opted to play it safe and keep these changes isolated.


> We could use $ENV{GIT_EXEC_PATH} instead of FindBin here though, I
> missed that the first time. But that's just a nano-optimization. I just
> wondered whether git wasn't already passing us this info.

Oh good idea - I'll go ahead and do this.

> There is one remaining bug here. Git::I18N isn't doing the right thing,
> I installed in /tmp/git and moved to /tmp/git2, and it has:
>     our $TEXTDOMAINDIR = $ENV{GIT_TEXTDOMAINDIR} || '/tmp/git/share/locale';
> And GIT_TEXTDOMAINDIR is not passed by git (it's only used for the tests
> IIRC). Would need a similar treatment as this. Easiest to just set the
> path we find here in $Git::Whatever and pick it up in $Git::I18N later,
> it's not like anyone uses it outside of git.git.

Good catch! I'm going to see what I can do here.

> But that does raise a more general concern for me. Isn't there some way
> we can run the test suite against an installed git (don't remember),
> then build, install, move the dir, and run the tests from the moved dir.
> That would have caught this bug, and anything else that may be lurking
> still.

I am not aware of such an option, but I'll take a look again. This sort of
thing might just require a reformulation of the test suite in general to
make it run against a Git installation instead of the intermediate
artifacts. A positive outcome would be the ability to remove the Perl
path environment variable hacks ($ENV{...} || ...) and just use production
resolution logic, increasing the test surface! But I think that's a bit more
work than I have time for at the moment.


> Noticed after I sent the last E-Mail, this is missing @@INSTLIBDIR@@
> which per my reading of it being initially introduced should be here in
> addition to this relative path.
> My reading of the intial patch that added it, as indicated in my patch,
> is that it's the dir we're going to be installing our libs to, so I
> didn't fiddle with it, but I think with your patches we need that dir
> *and* or own $perllibdir.

INSTLIBDIR is used for the standard fixed-prefix header, but not in this
one. This one uses a combination of GITEXECDIR and PERLLIBDIR. PERLLIBDIR
is effectively the prefix-relative part of INSTLIBDIR, so it's here in

Thanks for taking the time to review! I'll go ahead and see what I can do
RE your comments.


      reply	other threads:[~2017-11-29 22:38 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-29 15:56 [PATCH v4 0/4] RUNTIME_PREFIX relocatable Git Dan Jacques
2017-11-29 15:56 ` [PATCH v4 1/4] Makefile: generate Perl header from template file Dan Jacques
2017-12-01 16:59   ` Johannes Sixt
2017-12-01 17:13     ` Johannes Schindelin
2017-12-01 17:25       ` Johannes Sixt
2017-12-01 18:18         ` Dan Jacques
2017-12-01 18:52           ` Andreas Schwab
2017-12-05 20:54         ` Johannes Sixt
2017-12-05 21:17           ` Junio C Hamano
2017-12-05 21:26           ` Dan Jacques
2017-12-05 21:35             ` Junio C Hamano
2017-12-06 18:25               ` Johannes Sixt
2017-12-06 18:47                 ` Junio C Hamano
2017-12-06 18:56                   ` Daniel Jacques
2017-12-06 19:01                     ` Ævar Arnfjörð Bjarmason
2017-12-08 21:15                       ` Ævar Arnfjörð Bjarmason
2018-04-23 23:23                 ` [PATCH dj/runtime-prefix 0/2] Handle $IFS in $INSTLIBDIR Jonathan Nieder
2018-04-23 23:24                   ` [PATCH 1/2] Makefile: remove unused @@PERLLIBDIR@@ substitution variable Jonathan Nieder
2018-04-24  2:11                     ` Junio C Hamano
2018-04-23 23:25                   ` [PATCH 2/2] Makefile: quote $INSTLIBDIR when passing it to sed Jonathan Nieder
2018-04-24  0:53                     ` Junio C Hamano
2018-04-24  2:18                       ` [PATCH 2/2 v2] " Jonathan Nieder
2018-04-24  2:56                         ` Daniel Jacques
2017-12-03  5:26     ` [PATCH v4 1/4] Makefile: generate Perl header from template file Junio C Hamano
2017-12-03  9:26       ` Ævar Arnfjörð Bjarmason
2017-11-29 15:56 ` [PATCH v4 2/4] Makefile: add support for "perllibdir" Dan Jacques
2017-11-29 20:04   ` Ævar Arnfjörð Bjarmason
2017-11-29 15:56 ` [PATCH v4 3/4] Makefile: add Perl runtime prefix support Dan Jacques
2017-11-29 21:00   ` Ævar Arnfjörð Bjarmason
2017-12-02 15:47     ` [PATCH v4 3/4] RUNTIME_PREFIX relocatable Git Dan Jacques
2017-11-29 21:04   ` [PATCH v4 3/4] Makefile: add Perl runtime prefix support Ævar Arnfjörð Bjarmason
2017-11-29 15:56 ` [PATCH v4 4/4] exec_cmd: RUNTIME_PREFIX on some POSIX systems Dan Jacques
2017-11-29 21:12 ` [PATCH v4 0/4] RUNTIME_PREFIX relocatable Git Ævar Arnfjörð Bjarmason
2017-11-29 22:38   ` Dan Jacques [this message]

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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

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