e.mkdn

The upstream module in question has dual-build, so its not a show-stopper, however, our eclass situation is such that gentoo will:

1. In the presence of a Build.PL file, always used Module::Build style invocation, regardless of truth.

2. In the scenario where Build.PL is Not Module::Build, erroneously complain about a dependency on Module::Build, which is not necessary

3. Also entirely fail to QA check on the appropriate dependency when Build.PL requires some other things.

Essentially, the QA check we have in place is a bit wonky, and the mechanism that triggers it is wonky and unreliable too.

My Idea at present to solve this is:

• Establish a new variable in perl-module.eclass that is authoritative, PERL_MODULE_TOOLKIT

• PERL_MODULE_TOOLKIT should out of the box have 3 possible variables, eumm, mb, mbtiny , indicating the three primary toolkits in the wild ( module install excluded, because it is self bundling and works under eumm ).

• PERL_MODULE_TOOLKIT being defined, should forcibly inject relevant dependency atoms into DEPEND

• PERL_MODULE_TOOLKIT being undefined, should eventually be a QA Warning.

• a function should exist in perl-module.eclass, perl-module-toolkit(), the default implementation being to return the value of PERL_MODULE_TOOLKIT if defined, otherwise, exhibits a QA warning about PERL_MODULE_TOOLKIT being undefined and that leading to potentially unusual circumstances, then performs a "Sniff test" similar to what we currently do to determine the tool.

• a second function should exist in perl-module.eclass, perl-module-check-toolkit( name ) , which takes the toolkit sniffed (or declared) by perl-module-toolkit, and does more thorough analysis to make sure the dist in question resembles the stated toolkit enough to work.

To guard against upstream changing tooling between releases and us not noticing during bumping, and having subsequent dependencies broken:

• for mb and mbtiny, this means dying if there is no Build.PL

• for eumm this means dying if there is no Makefile.PL

• for mb , Build.PL must match /(^|\W)use\s+Module::Build[\s;]/or /(^|\W)require\s+Module::Build[\s;]/

• for mbtiny , Build.PL must match /(^|\W)use\s+Module::Build::Tiny[\s;]/or /(^|\W)require\s+Module::Build::Tiny[\s;]/

A Subsequent QA warning should also be emitted if the toolkit being checked does not occur in DEPEND= , not only are we entirely reliant on auto-detection, but the auto-detected toolkit is not a dependency.

Though, I think its high time we had a perl-module-r1.eclass to cut all the non-eapi5 eapis out cleanly.

This approach should be much more resilient than determining how tooling will work by luck, or by grepping DEPEND, and should be more flexible with adding future tooling.

perl-module-toolchain() should be called everywhere that a toolchain needs to be determined.

perl-module-check-toolchain() should be called in src_prepare()

perl-module.eclass

#
# local somevar;
# perl-module-toolkit somevar; # somevar contains sniffed toolkit
# 
perl-module-toolkit() {
	local _output=$1;
	local _result='';
	if [[ -n ${PERL_MODULE_TOOLKIT} ]]; then
		_result=${PERL_MODULE_TOOLKIT};
		eval $_output=\$_result;
		return 0;
	fi
	eqawarn "QA Notice: The ebuild does not declare PERL_MODULE_TOOLKIT to determine install process"
	eqawarn "           Reverting to sniffing may cause later subtle errors";
	if [[ -n ${PERLQAFATAL} ]]; then
		eerror "Bailing due to PERLQAFATAL=1";
		die;
	fi
	if [[ -f Build.PL ]]; then
		if grep 'Module::Build::Tiny' Build.PL >/dev/null; then
			einfo "Sniffed Module::Build::Tiny";
			_result="mbtiny";
			eval $_output=\$_result;
			return 0
		fi;
		einfo "Sniffed Module::Build";
		_result="mb";
		eval $_output=\$_result;
		return 0;
	fi
	if [[ -f Makefile.PL ]]; then
		einfo "Sniffed ExtUtils::MakeMaker";
		_result="eumm";
		eval $_output=\$_result;
		return 0;
	fi;
	eerror "Could not determine PERL_MODULE_TOOLKIT automatically. Bailing";
	die;
	return 1;
}