Closed kentfredric closed 3 years ago
kentfredric
commented
4 years ago Meant to say:
EVEN THOUGH it is fully ABI inter-compatible with their current perl, due to the tiny quirk about @INC handling being terrible.
And the code in question is PurePerl, does no funny business, and has existed unchanged for 20 years.
jkeenan
commented
3 years ago There's presently only two options for adding paths to
@INC, and both of them are unsuitable for my use.Keep in mind, this is in a context where I'm already well aware of how ABI works, and I'm quite capable of deciding what is, and what isn't, a valid directory to put in
@INCmyself.
[snip]
The OP is unfortunately no longer available to pursue his request in this ticket or to respond to questions about it. I've tried to wrap my head around it and can't claim to fully understand it. But I'm skeptical that we should consider adding Configure variables for particular OS distributions.
Thoughts from readers?
jkeenan
commented
3 years ago There's presently only two options for adding paths to
@INC, and both of them are unsuitable for my use. Keep in mind, this is in a context where I'm already well aware of how ABI works, and I'm quite capable of deciding what is, and what isn't, a valid directory to put in@INCmyself.[snip]
The OP is unfortunately no longer available to pursue his request in this ticket or to respond to questions about it. I've tried to wrap my head around it and can't claim to fully understand it. But I'm skeptical that we should consider adding
Configurevariables for particular OS distributions.Thoughts from readers?
No comments in nearly 8 months; closing.
There's presently only two options for adding paths to
@INC, and both of them are unsuitable for my use.Keep in mind, this is in a context where I'm already well aware of how ABI works, and I'm quite capable of deciding what is, and what isn't, a valid directory to put in
@INCmyself.Current Option -Dinc_version_list
This is useless, because it takes what you pass it as a suggestion, and then internally mangles it, giving a different output than was asked for.
On one build, I passed:
With the intent on building a perl with its INSTLIB being "/usr/lib64/perl5/5.30" (or something like that, not the intentionally missing trailing digit ), and something "clever" in Perl gives me this:
And importantly, this strategy seems impossible to use to build perl's for to explicitly include directories that dont exist on your system, because you know they do exist on the deployment system(s).
But the TL;DR version is "Perl is trying to be too clever", I could unpick that clever and work out where its going wrong, but I don't have the patience to bash my head into that wall, I just need something that listens to what I say and does it exactly how I said to do it, regardless of how foolish that may be.
Current option -Dotherlibdirs
This, is differently useless, in that although it does allow you to build with support for directories that don't exist, ... it then gets extra clever and decides to tack on archlib dirs to it.
Which is expressly something I dont want to do, and didn't ask for.
The objective here is to use these dirs as a "last resort backup plan", so that during upgrades, all pureperl packages that have yet to be reinstalled into the "new perl's" INSTDIR continue to work as best as possible (because sometimes, the package manager gets build order wrong and tries to use things that rely on things that are effectively broken by the upgrade of perl, due to falling outside of
@INC, and as much as I try, there is nothing I can do to make that problem go away, other than to make perl less likely to break in that situation ). And yes, that could break when there are XS deps in the loop, and that's an understood caveat. But it would be better to not have those XS deps in the loadable path, and it would be better for perl to croak with a "can't find XS module foo" ( which may even safe-fail inside an eval ), than to have perl try to load a binary object with incompatible ABI.My bodgearound
So, what I've hacked together instead, is this terrible bodge, because I don't fully understand the mess of C and Configure involved. But it works!
The important part being
INCPUSH_ADD_OLD_VERS|INCPUSH_CAN_RELOCATEwithoutADD_ARCHONLY_SUBDIRSAnd the end result?
And this is superior in every way to the options presently made available by configure.
Footnote
Yes, some of this drama precipitates due to having 2 different version schemes in employ for the layout. Full version 5.x.y is the standard pattern, and 5.x is something I'm simply experimenting with, because other problems have reared there head lately due to the aforementioned "oh noes, I can't specify directories that don't exist and have them work" issue.
eg:
@INChandling being terrible.But at least in my case, one can be confident that we have the tools to automatedly determine the right paths, in advance, explicitly, and all that's needed is a good way to throw them over to perl without it getting "special" and undoing our work.
Perhaps something better than my crude hack can be employed.