Created attachment 365910 [details, diff] perl-module.eclass.patch dev-perl/Module-Build-Tiny::perl-experimental doesn't support pure_install target. Attached patch this this issue. I was able to build several modules based on Module::Build::Tiny with that patch, using trivial ebuilds auto-generated with g-cpan, and without using perl-mb-tiny.eclass from perl-experimental. Example of such modules: Dist-Zilla-Plugin-ReversionOnRelease, Dist-Zilla-Plugin-ModuleBuildTiny.
Hm, a novel approach. It should work I guess. I'm paranoid of the risk that something will depend on MBTiny, but not use it as a tool, but atm, the risk of that seems narrow. My only real opposition is we have a very complicated eclass as it is, and there's lots of conditional logic to switch between MB and EUMM as it is, and I'd like to move away from that if possible. For instance, there's distutils.eclass and twisted.eclass for python ( in addition to the main python(.*).eclasses ) And of course, for C, we have autotools vs cmake tooling. Sure, they should still share some logic, but deciding how to build things at compile time is a little late for my liking. ( Let alone, re-deciding in every phase like we presently do, based on the presence of certain files )
Any chance to have this ever fixed?
Be sure to read my comments and linked gists on related bug #497348 , and my opinion is that sort of stuff should be ideally determined by g-cpan and hinted in the ebuild as to how to work.
Ok, in response to the github discussion[1], I've made this patch to perl-experiemental: https://github.com/gentoo-perl/perl-experimental/commit/49ec79fcc3863ca26369ceb1ded509c0cdc36165 The TLDR for dilfridge is in comment [2], but basically, the pure_install target was a provisional future proof in the first place, and has until now been identical to "install" and we've just used pure_install in the event "install"s eventual plans to change transpire. `install --pure` does the same thing, simply by symptom of the fact `--pure` does *NOTHING*, but is provisionally under discussion to enable pure mode in the event `install` ever has non-pure behaviour. So this patch simplifies the Module::Build family logic and isolates it from EUMM logic, and there's still sniffing going on, but only for QA checks, not install-time behaviour modification. And this solution I imagine will please everyone. 1: https://github.com/Leont/module-build-tiny/issues/7 2: https://github.com/Leont/module-build-tiny/issues/7#issuecomment-67964193
Created attachment 397180 [details, diff] perl-module.eclass.patch A transformation of the patch I've long been using on the overlay with no complaints adapted for the ::gentoo eclass. Note: This is transposed by hand and has yet to be thoroughly tested with the ::gentoo tree.
*** Bug 541878 has been marked as a duplicate of this bug. ***
+ 15 Mar 2015; Andreas K. Huettel <dilfridge@gentoo.org> perl-module.eclass: + Detect dangerous environment variables, bug 543042; support + Module::Build::Tiny directly, bug 495044 +
