From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-2.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 7681F1F406 for ; Mon, 8 Jan 2018 09:41:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932079AbeAHJlY (ORCPT ); Mon, 8 Jan 2018 04:41:24 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:35697 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932076AbeAHJlV (ORCPT ); Mon, 8 Jan 2018 04:41:21 -0500 Received: by mail-wm0-f45.google.com with SMTP id a79so12938413wma.0 for ; Mon, 08 Jan 2018 01:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:user-agent:in-reply-to:date :message-id:mime-version; bh=nIbTMVYn87W8PCf5xVXZNXwWXlNGKYbzFIcMTEAOWZ0=; b=bcWc6C7sIWGj53dIIsYW8UmuC4cthDTuiMz7t1ycYKNOw473kZRvX+laMyjzLgTgVE dqW7X4JHz8qSnsrFNR1075HYnOXnb7oVKQKGuYw/pm6wXvP8B9svcmZ8ffmodCeaayTt PjPUmKxnOMUuwevznjI+pr2Y03FZJlA36a0uKoqRvA/E/b8yAkD0WcOumXrKYiClM54s zfVH927zlBWJ6pW+7Wk2ivSupkLwgysu2qpPsAGXROQmij4pIzrzYFD+HDr0beDrSUn/ AtjhW3rHmrbuw6U5leK9EkmYCMdQ8/mDeq4dbxUo1ATLNaD5hrpw/JzFPAKpU54BXbg6 joUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:user-agent :in-reply-to:date:message-id:mime-version; bh=nIbTMVYn87W8PCf5xVXZNXwWXlNGKYbzFIcMTEAOWZ0=; b=W3G68z+4sbtDzLu2h3RYukYgVQzYkOLImVJkjrhxWygfwW5d20AY0U/s7lYpfJSmx8 CHCdbgWuPDlCa5BaqtUATq5VCAUjhjcwkYB6pZITIkDHtgCr+jbY+NCVKhy6M9wr8XC7 pjOyY+jZlupnd8eBfHq2XZ1gKE5wQPTQzQCVZWKtnDvsLy0EzcDnzJxjcKPr9tA5gKbV o0PRXR9uzLgCUUD9UyKw2wgclTB5CGwJmMoULmmOv5QkaaOnmmkciTPvksXWXwcxKrvu 3j8j64sWCNxov9n1Z5ZvqHZf3YVnEgmzImeUhzcuBUyWyHn5AFHXCeB3AyhiFyHHNHOm maJw== X-Gm-Message-State: AKGB3mLcCsJabGx6n5U2x1DauC3Q5TNgeQW4ZeZ4JClTiWQd5IoQSaa2 qHLN6DDzyhAEMG5X8hsSQJE= X-Google-Smtp-Source: ACJfBouHBVfYjvhYiQZsVhiK8fY1jKqc6iMYmGLn15QFXgO1YKdWzCbhLU8mBTruHiqItLbomAqKAw== X-Received: by 10.80.182.83 with SMTP id c19mr15397268ede.126.1515404479772; Mon, 08 Jan 2018 01:41:19 -0800 (PST) Received: from evledraar (proxy-gw-a.booking.com. [5.57.21.8]) by smtp.gmail.com with ESMTPSA id b30sm7679840ede.53.2018.01.08.01.41.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Jan 2018 01:41:17 -0800 (PST) From: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason To: Dan Jacques Cc: git@vger.kernel.org, gitster@pobox.com, Johannes.Schindelin@gmx.de Subject: Re: [PATCH v5 2/3] Makefile: add Perl runtime prefix support References: <20180108030239.92036-1-dnj@google.com> <20180108030239.92036-3-dnj@google.com> User-agent: Debian GNU/Linux 9.3 (stretch); Emacs 25.1.1; mu4e 0.9.19 In-reply-to: <20180108030239.92036-3-dnj@google.com> Date: Mon, 08 Jan 2018 10:41:16 +0100 Message-ID: <87inccbscj.fsf@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, Jan 08 2018, Dan Jacques jotted: Thanks, applied this on top of next and it works for me, i.e. install to /tmp/git and move to /tmp/git2 = works for me. Comments below. > Enabling RUNTIME_PREFIX_PERL overrides the system-specific Perl script > installation path generated by MakeMaker to force installation into a > platform-neutral location, "/share/perl5". Not generated by MakeMaker anymore :) >From 3/3 (not not send 2 e-mails): >+# it. This is intentionally separate from RUNTIME_PREFIX so that notably Windows >+# can hard-code Perl library paths while still enabling RUNTIME_PREFIX >+# resolution. Maybe we covered this in previous submissions, but refresh my memory, why is the *_PERL define still needed? Reading this explanation doesn't make sense to me, but I'm probably missing something. If we have a system where we have some perl library paths on the system we want to use, then they'll still be in @INC after our 'use lib'-ing, so we'll find libraries there. The only reason I can think of for doing this for C and not for Perl would be if you for some reason want to have a git in /tmp/git but then use a different version of the Git.pm from some system install, but I can't imagine why. Or there's another option... > + # GIT_EXEC_PATH is supplied by `git` or the test suite. Otherwise, resolve > + # against the runtime path of this script. > + require FindBin; > + require File::Spec; > + (my $prefix = $ENV{GIT_EXEC_PATH} || $FindBin::Bin) =~ s=${gitexecdir_relative}$==; So why are we falling back on $FindBin::Bin? Just so you can do e.g. /tmp/git2/libexec/git-core/git-svn like you can do /tmp/git2/libexec/git-core/git-status, i.e. will this never be false if invoked via "git"? I don't mind it, just wondering if I'm missing something and we need to use the fallback path in some "normal" codepath. > + return File::Spec->catdir($prefix, $relpath); I think you initially got some version of this from me (or not), so this is probably my fault, but reading this again I think this would be better as just: return $prefix . '@@PATHSEP@@' . $relpath; I.e. right after this we split on @@PATHSEP@@, and that clearly works (as opposed to using File::Spec->splitpath) since we've used it forever. Better just to use the same idiom on both ends to not leave the reader wondering why we can split paths one way, but need to join them another way.