How to get Module-Build-Tiny-0.048 to pass all of its tests.

[sisyphus]

I note that SP-5.40.0.1-PDL builds Module-Build-Tiny-0.048 just fine, with all tests passing.
(There's a whole lot of junk at the end about temp files not being cleaned up, but that's not really an issue.)

Whenever I try to build the module, the final test ('Script is installed') always fails (as per Perl-Toolchain-Gang/module-build-tiny#35).

I've spent a couple of hours trying to work out what SP has done that enables all tests to pass ... but haven't yet found the key.

Does anyone have any tips ?

[shawnlaffan]

It's not built directly so must be done as a prereq for another module.

Possibly that is run with the ignore_testfailure flag set (which I assume propagates to dependencies but I have not checked).
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/blob/master/share/64bit-5.40.0.1.pp

Edit -

Although that's not what you're reporting...

What about the various config settings that control script installation location and the like?

[sisyphus]

What about the various config settings that control script installation location and the like?

Yeah ... maybe. (I compared the environment settings, and found no unexpected difference except for a HOME setting, to which I attended.)

5.40.0.1-PDL does actually successfully build M-B-T-0.048 (and pass all tests) when I do a manual build of that module.
But all of my other perl-5.40.0 builds will fail the final test, as per Perl-Toolchain-Gang/module-build-tiny#35.

I've built a quadmath perl-5.40.0 from source, using the toolchain provided by SP 5.40.0.1-PDL, and set it up to use the 3rd party libraries provided by that SP build.
I'm curious to see how those libraries (and all of the perl modules also) go with a quadmath build of perl ... and I certainly don't want to go to the trouble of building all of those libraries myself ;-)

Having built that perl, I've started working through the list provided in DISTRIBUTIONS.txt, and leaving the "Alien" stuff till last,
I'm being careful to install the same version as specified in DISTRIBUTIONS.txt, but I've hit this anomaly with M-B-T-0.048 when it came to installing App-pmuninstall.
I don't think this is "quadmath" issue.

It's not a big deal, and there's no hurry for me to complete the task, so I'll just keep pushing on .... and I'll try to keep my "pestering" to a minimum.

I think it's worthwhile understanding how it has come about that SP-5.40.0-PDL avoids this issue with M-B-T-0.048, while so many other builds don't - so I'll leave this open.

[shawnlaffan]

Is it perhaps related to the architectured setup described in Perl-Toolchain-Gang/ExtUtils-MakeMaker#459 (comment)?

[sisyphus]

Seems to me that Windows is probably the only system where builds of perl from "straight-out-of-the-box" perl source will invariably leave "installsitescript" as the empty string.
On Ubuntu, MSYS2, and Cygwin the system perls, and my own personal builds, all set "installsitescript" to a sensible value.

On the basis of what I see them doing, I think I'll prepare a PR (to win32/config.gc and win32/config.vc) in the next day or two, such that Windows perl builds will set "installsitescript" to the same string as "installscript".

However, given that we now know that there are perl builds around that have "installsitescript" set to the empty string, it's probably a good idea that EU::MM and/or EU::Config are also patched to handle that scenario.

Do you know why it is that Strawberry Perl wants/needs to customize the setting of these values in the way it does ?
I mean, why can't these 4 "Install..." options all just specify "Strawberry_path\perl\bin" ?

[shawnlaffan]

Do you know why it is that Strawberry Perl wants/needs to customize the setting of these values in the way it does ?
I mean, why can't these 4 "Install..." options all just specify "Strawberry_path\perl\bin" ?

It all pre-dates my work on the project.

https://github.com/search?q=repo%3AStrawberryPerl%2FPerl-Dist-Strawberry%20installsitescript&type=code

My change on this front was to collate the changes into one place in 78adc57 to avoid having to patch Config.gc for every build.

[shawnlaffan]

Hmm. That last response does not answer the question as posed.

It still pre-dates me, but it makes sense to keep the core perl stuff separate from the vendor-built stuff (done as part of the SP build process) from those built by users themselves. There is less risk that way of overwriting critical components when a module update goes wrong.

[sisyphus]

Oh, yeah - seems reasonable.
I'll be suggesting this change to win32/config.gc:

--- perl-5.41.3/win32/config.gc 2024-07-25 00:58:48.000000000 +1000
+++ perl-5.41.31/win32/config.gc        2024-09-05 13:15:13.128424900 +1000
@@ -849,7 +849,7 @@
 installsitelib='~INST_TOP~\site~INST_VER~\lib'
 installsiteman1dir=''
 installsiteman3dir=''
-installsitescript=''
+installsitescript='~INST_TOP~~INST_VER~\bin'
 installstyle='lib'
 installusrbinperl='undef'
 installvendorarch=''

I take it that change would have no impact at all on Strawberry perl builds.

[shawnlaffan]

Looks good to me

[sisyphus]

I later realized that installscript and installsitescript should honour ~INST_ARCH~ as is done by installbin and installsitebin.
Hence: Perl/perl5#22581

[sisyphus]

Perl/perl5#22581 has been merged.