Re: *more* relocatable perl

(Blabos responded privately, suggesting plenv / perl-build; I may have
not explained myself clearly enough, let me try again)

I suspect we're using different definition of "relocatable"

If I build a perl (by hand, with perlbrew, with perl-build, I'm pretty
sure it doesn't make a difference) to (for example)
`~/perl5/perlbrew/perl-5.44.0/`, then I *move* that whole directory
tree somewhere else:

    mv ~/perl5/perlbrew/perl-5.44.0/ ~/src/myproject/perl
    export PATH=~/src/myproject/perl/bin:$PATH

and then try to install (let's say) `Archive::Zip`, the tests will fail.

Those tests (see
https://metacpan.org/release/PHRED/Archive-Zip-1.68/source/t/common.pm#L104
) use `$Config{perlpath}` to find a working perl. But since I moved it
away from where it was initially installed, the `perl` is no longer
there (and nothing updated `Config.pm`).

There are also distributions that use `ExtUtils::Helpers`
`make_executable` which uses `$Config{startperl}`
https://metacpan.org/release/LEONT/ExtUtils-Helpers-0.028/source/lib/ExtUtils/Helpers/Unix.pm#L21
which, again, will point to the path that perl was initially installed
to.

For my particular case, I have patched `Config.pm` so it treats those
settings pretty much the same way as the various "libs" when
`userelocatableinc` is enabled: the original installation prefix gets
replaced by whatever the path to `$^X` is.

My suggestion was to incorporate that hack in the normal Configure
process. Or maybe to tell me why it can't be done, or shouldn't be
done.

-- 
	Dakkar - <Mobilis in mobile>
	GPG public key fingerprint = A071 E618 DD2C 5901 9574
	                             6FE2 40EA 9883 7519 3F88
	                    key id = 0x75193F88