Æ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?
