mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: Dan Jacques <>
Subject: Re: [PATCH v4 0/4] RUNTIME_PREFIX relocatable Git
Date: Wed, 29 Nov 2017 22:12:55 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Nov 29 2017, Dan Jacques jotted:

> This is a small update to incorporate some Windows fixes from Johannes.
> At this point, it passes the full test suite on Linux, Mac, and FreeBSD,
> as well as the test suites, with and without
> I'm happy with the patch set, and feel that it is ready to move forward.
> However, while it's been looked at by several people, and I have
> incorporated reviewer feedback, the patch set hasn't received any formal
> LGTM-style responses yet. I'm not sure what standard of review is required
> to move forward with a patch on this project, so maybe this is totally
> fine, but I wanted to make sure to point this out.
> I also want to note Ævar Arnfjörð Bjarmason's RFC:
> The proposed patch set conflicts with the Perl installation directory
> changes in this patch set, as avarab@ notes. The proposed Perl installation
> process would simplify patch 0002 in this patch set. I don't think the
> landing order is terribly impactful - if this lands first, the patch in the
> RFC would delete a few more lines, and if this lands later, patch 0002
> would largely not be necessary.

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.

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.

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.

  parent reply	other threads:[~2017-11-29 21:13 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 ` Ævar Arnfjörð Bjarmason [this message]
2017-11-29 22:38   ` [PATCH v4 0/4] RUNTIME_PREFIX relocatable Git Dan Jacques

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