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

I don't think any module authors ever deal with it.

I think you're right about that.
And, wrt my own modules, I'm now happy to utilize the solution that hippo provided.

But there's the question of what to do about other people's modules on CPAN.
For example, there's the pure-perl module Math::AnyNum that depends upon a number of perl extensions.
Should I suggest to the Math::AnyNum author that he also apply hippo's fix to his module ?
Or should I just deal with it myself ? - either by patching the Math::AnyNum Makefile.PL, or by doctoring the make install command as suggested by hv ?
I tend to think that it's probably up to me to deal with it privately, but I might mention the issue to the Math::AnyNum author to ensure that he's at least aware of the issue.

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 hippo (Archbishop) on Sep 24, 2022 at 11:48 UTC
I tend to think that it's probably up to me to deal with it privately I agree. Any pure-perl module, regardless of whether it depends on impure modules at any depth, should go in the architecture-independent lib path by default. How else would you deal with the case where the deep dependencies change either to or from XS? Or vary depending on other factors? Your particular use case is far enough from the mainstream that it is IMHO up to you to set the necessary flags when installing such modules to meet your specific requirements. 🦛	[reply]
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 13:02 UTC
Your particular use case is far enough from the mainstream that it is IMHO up to you to set the necessary flags when installing such modules to meet your specific requirements. Cool ... I can live with that ... and thanks for taking the time to express that view. However, although my use case is not mainstream, I'll point out that it's still (AFAICS) an officially endorsed use case. And that muddies the waters a little, IMO ... but probably not enough to make much difference. I assume that there's no objection to my enforcing the installation of my Module::A (Math::FakeDD) into $Config{installsitearch} for all who attempt to install the module. Someone should let me know if that's a bad assumption. (There's no guarantee that anyone other than me would want to install that module, anyway.) Cheers, Rob Update: Math-FakeDD-0.05 also now available at cpan.	[reply]