Re^2: How to tell EU::MM to install a pure-perl module into an architecture-specific location

SorryAM, I missed your post while I was investigating and composing my reply to tobyink's.
Again, I'm still faced with the table that I simply don't understand.

I probably should just add an XS file (containing a meaningless and pointless XSub) to the Module::A distro, as that act alone would ensure that the module gets installed into INSTALLSITEARCH ;-)))

Cheers,
Rob

Comment on Re^2: How to tell EU::MM to install a pure-perl module into an architecture-specific location Download Code

Replies are listed 'Best First'.
Re^3: How to tell EU::MM to install a pure-perl module into an architecture-specific location by hv (Prior) on Sep 23, 2022 at 12:56 UTC
The non-arch-specific files (INST_LIB) will be installed to INSTALLSITELIB, but you want them in the arch-specific site directory (INSTALLSITEARCH). So I think the comments so far (plus those docs) suggest that you could parse out the value of INSTALLSITEARCH from `perl -V:installsitearch`, then override INSTALLSITELIB to that value: perhaps at make time with something like make install INSTALLSITELIB=`find_archlib`. It is not clear however why you don't simply put each perl build in a separate hierarchy. That would give you the separation you want in a far cleaner and more obvious manner. I think the assumption underlying the existing directory layout is that things can and will be tested in isolation: if Module::B passes its tests and gets installed on each of perl-X and perl-Y, then it should not matter which of them the pure-perl Module::A has been tested against. If it does matter, that suggests either that there are tests missing for Module::B, or that there is code in one module that should be in the other.	[reply] [d/l] [select]
Re^4: How to tell EU::MM to install a pure-perl module into an architecture-specific location by syphilis (Archbishop) on Sep 24, 2022 at 06:46 UTC
It is not clear however why you don't simply put each perl build in a separate hierarchy I used to do that, but the repeated duplication of hunks of perl didn't fit well with my frugal nature and my sense of orderliness. Perl already offered the option to take this alternative approach, so I thought "why not". I would have gone ahead with the change even if I had been aware of this issue - and I'm still happy that I did go ahead with it. If it does matter, that suggests either that there are tests missing for Module::B, or that there is code in one module that should be in the other It's quite possible for bugs to exist for just one architecture - maybe because a pre-requisite is at a different version, or because a need specific to one architecture has been overlooked. I just want to do what I can to ensure that any such bugs affecting my module are caught. Cheers, Rob	[reply]