perl-toolchain-gang / module-build Goto Github PK

View Code? Open in Web Editor NEW

32.0 32.0 36.0 7.71 MB

Perl module to configure and build modules (what backs most Build.PLs)

Home Page: https://metacpan.org/release/Module-Build

Perl 99.91% Batchfile 0.09%

module-build's People

Contributors

Stargazers

Watchers

module-build's Issues

Lots of non-old-core dependencies

Although the documentation for M::B says the following right at the top of the main page (something I'll have to correct):

Its only prerequisites are modules that are included with perl 5.6.0, and it
works fine on perl 5.005 if you can install a few additional modules.

The truth: now that M::B is in core, it actually depends on many newer modules than that:

CPAN::Meta 2.110420 was released with perl v5.13.10
CPAN::Meta::YAML 0.003 was released with perl v5.13.9
ExtUtils::CBuilder 0.27 was released with perl v5.11.2
ExtUtils::Manifest 1.54 was released with perl v5.8.9
ExtUtils::ParseXS 2.21 was released with perl v5.11.1
File::Spec 0.82 was released with perl v5.6.1
File::Temp 0.15 was released with perl v5.8.7
Module::Metadata 1.000002 was released with perl v5.13.9
Parse::CPAN::Meta 1.4401 was released with perl v5.13.10
Perl::OSType 1 was released with perl v5.13.9
Test::Harness 3.16 was released with perl v5.10.1
Test::More 0.49 was released with perl v5.8.7
version 0.87 was released with perl v5.13.9

When M::B leaves the core, that means that none of these distributions can use M::B for their installation process (not sure whether any of them actually do right now), because that will generate a circular dependency.

One bummer of leaving the core.

install failed using cpanm in Mac

Result: PASS
Building Module-Build
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ERROR: Can't create '/home/hwu/perl5/bin'
mkdir /home/hwu: Operation not supported at /Users/hwu/perl5/perlbrew/perls/perl-5.28.0/lib/5.28.0/ExtUtils/Install.pm line 489.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
at lib/Module/Build/Base.pm line 3565.
FAIL
! Installing Module::Build failed. See /Users/hwu/.cpanm/work/1543736391.13991/build.log for details. Retry with --force to force install it.

seems to me the correct directory should be '/Users/hwu/perl5/perlbrew/bin' in Mac(MacOS majave 10.14.1)?
Perl Version: This is perl 5, version 28, subversion 0 (v5.28.0) built for darwin-2level
(with 1 registered patch, see perl -V for more detail)

Test::More propagated from META.yml build_requires to MYMETA.json build_requires

This difference is one I haven't noticed before:

diff -Naur META.json MYMETA.json 
--- META.json   2013-11-13 04:41:11.608851524 +1300
+++ MYMETA.json 2013-11-13 04:41:24.652856206 +1300
@@ -16,7 +16,8 @@
    "prereqs" : {
       "build" : {
          "requires" : {
-            "Module::Build" : "0.4200"
+            "Module::Build" : "0.4200",
+            "Test::More" : "1.001002"
          }
       },
       "configure" : {

Not sure if this intentional or not.

I removed all instances of Test::More in Build.PL , still turned up.
I removed all instances of Test::More in META.json, still turned up.
Only once I removed Test::More from META.yml, did it cease appearing in MYMETA.json

Which is odd, because in META.json, Test::More is only test.requires, but in META.yml, Test::More is build.requires because the .yml spec doesn't support test_requires

Seems odd to prefer META.yml to META.json when both exist.

( META.(yml,json) and Build.PL are all generated by Dist::Zilla, MYMETA.json emitted by Module::Build 0.4200 )

install_path doesn't work with custom hash attribute

I am getting this error when I try to use --install_path on distributions that use a subclass of Module::Build which have their own custom hash properties:

grunion% perl Build.PL --install_path lib=/util/lib/perl
Can't use string ("lib=/util/lib/perl") as a HASH ref while "strict refs" in use at /web/opt/perl/5.14/site/share/Module/Build/Base.pm line 2240.

The specific subclass that I am dealing with is Module::Build::Database. I believe this to be a bug in Module::Build and not in ::Database, but am happy to make changes to ::Database if that proves not to be the case.

Here is my solution, which may not be the right one (though at least it does pass the existing test suite):

https://github.com/plicease/Module-Build/commit/03de0b085d97a6c55b21de1f46e0f06ce4bac5c0

Test::More dependency not declared?

I just tried installing Module::Build 0.4005 on a 5.10.1 under cygwin and got a bunch of messages like this:

t/metadata.t ................... Checking prerequisites...
  test_requires:
    !  Test::More (0.92) is installed, but we need version >= 0.98

ERRORS/WARNINGS FOUND IN PREREQUISITES.  You may wish to install the versions of the modules indicated above before proceeding with this installation

Updating Test::More silenced those. I'm unsure if that's to do with my Perl or M::B itself.

Missing list of feature dependencies in warning for Module::Build features.

tl;dr... we need a way to get at the values of %$auto_features from Module::Build::ConfigData.

_warn_mb_feature_deps is for warning about missing Module::Build features, as opposed to features of the current distribution. For example, without Software::License MB can't generate a LICENSE file. Here's an example from perl5i.

$ PERL5OPT=-MDevel::Hide=Software::License ./Build distmeta
Devel::Hide hides Software/License.pm
Devel::Hide hides Software/License.pm
Devel::Hide hides Software/License.pm
Devel::Hide hides Software/License.pm
Creating README using Pod::Text
Creating LICENSE file
The 'license_creation' feature is not available.  Please install missing

feature dependencies and try again.

Aborting.

There's supposed to be an additional message there, generated by _feature_deps_msg, which tells the user what modules to install. Its missing.

_warn_mb_feature_deps incorrectly uses _feature_deps_msg which references the distribution's features (in this example its perl5i) not Module::Build's. Unfortunately I see no way to get the list of auto features out of Module::Build::ConfigData.

The "restrictive" license type is no longer supported correctly.

I believe the offending change to be dde4874, but I am not 100% certain.

scott@cricket:~/code/say/pigeon> perl Build.PL
Can't find dist packages without a MANIFEST file
Run 'Build manifest' to generate one

WARNING: Possible missing or corrupt 'MANIFEST' file.
Nothing to enter for 'provides' field in metafile.
Could not get valid metadata. Error is: Invalid metadata structure. Errors: License 'restrictive' is invalid (license -> restrictive) [Validation: 2]
 at /home/scott/opt/perlbrew/perls/perl-5.16.3/lib/site_perl/5.16.3/Module/Build/Base.pm line 4546.

This worked in versions prior to 0.42.

Installation fails on ActivePerl without environment setting

If the environment variable ACTIVEPERL_CONFIG_SILENT is not set to 1, the build harness emits a warning, causing t/unit_run_test_harness.t to fail.

See Perl-Toolchain-Gang/ExtUtils-MakeMaker#65 for a related fix on EU::MM.

This is perl, v5.8.9 built for MSWin32-x86-multi-thread
(with 12 registered patches, see perl -V for more detail)

Copyright 1987-2008, Larry Wall

Binary build 826 [290470] provided by ActiveState http://www.ActiveState.com
Built May 24 2009 09:21:05

option precedence needs to be reviewed

c.f. discussion in 886abd6

tl;dr: precedent of options set by .moduledefaultrc, PERL_MB_OPT and the command line should be reviewed. It should most likely be as follows:

# during Build.PL
.modulebuildrc supplied info
PERL_MB_OPT supplied info
things I passed when calling Build.PL

# during ./Build action_name
merged results of calling Build.PL
.modulebuildrc supplied info for action_name
things I passed when calling ./Build action_name

Meta 2.0 support

To make proper use of Meta 2.0, we need to convert our internals to use it instead of the current 1.4. This has backwards compatibility considerations however.

please stick in amount of digits used for version

Hi,

your switching between 2 (0.40) and 4 (0.3800) digits.
I know that this is no problem in "The perl world" where 0.40 > 0.3800, but in the "RPM world" 0.40 < 0.3800

Thanks in advance.
Cheers
Chris

'meta_merge' is not a known MakeMaker parameter name.

This works earlier, but now does not work.

kes@work ~/d $ ./Build install
Building DB-Hooks
creating Apache/perl5db.pl from /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/lib/5.36.1/perl5db.pl
WARNING: meta_merge is not a known parameter.
'meta_merge' is not a known MakeMaker parameter name.
Could not open 'DB.pm': No such file or directory at /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/lib/5.36.1/ExtUtils/MM_Unix.pm line 3006.
lib/Apache/Apache-DB-0.18/Makefile.PL failed at /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/lib/site_perl/5.36.1/Module/Build/Base.pm line 2951.

But this still works fine:

kes@work ~/d $ ./Build dist
Creating Makefile.PL
Created META.yml and META.json
Creating DB-Hooks-0.01_05
Creating DB-Hooks-0.01_05.tar.gz

kes@work ~/d $ ./Build distinstall
Creating Makefile.PL
Created META.yml and META.json
Creating DB-Hooks-0.01_05
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'DB-Hooks' version '0.01_05'
Building DB-Hooks
Building DB-Hooks
Installing /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/lib/site_perl/5.36.1/Apache/DB.pm
Installing /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/lib/site_perl/5.36.1/DB/Commands.pm
Installing /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/lib/site_perl/5.36.1/DB/Hooks/Server.pm
Installing /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/lib/site_perl/5.36.1/Devel/DebugHooks/Commands.pm
Installing /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/man/man3/Apache::DB.3
Installing /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/man/man3/DB::Hooks.3
Installing /home/kes/perl5/perlbrew/perls/perl-5.36.1-shrd-ithrd/man/man3/Devel::DebugHooks.3

May you please fix fist command to work.

Module::Build 0.42 Broke optional dependency handling.

Please see the comment on what I believe to be the offending commit.

Version 0.29 missing from CPAN and GitHub Releases

Hello,

I'm looking for version 0.29 of Module::Build, one of the dependencies for inc::Module::Install, which Net::SSLeay 1.49 depends on.

Proceeding with collecting packages, the dependency path so far looks like

HTTP::Tiny (latest, 0.088)
  Net::SSLeay 1.4.9
    use::Module::Install 1.21
      Module::Build 0.29

On CPAN, I only see links to versions 0.2808_05 and 0.30.

On GitHub Releases, I checked https://github.com/Perl-Toolchain-Gang/Module-Build/tags?after=0.3602, but 0.29 is missing.

After fetching Module-Install-1.21 from CPAN, attempting install on OpenBSD 7.2:

$ cd Module-Install-1.21
$ perl -I$HOME/perl/lib Makefile.PL PREFIX=$HOME/perl/lib
...
Checking if your kit is complete...
Looks good
Warning: prerequisite File::Remove 1.42 not found.
Warning: prerequisite Module::Build 0.29 not found.
...
Generating a Unix-style Makefile
Writing Makefile for Module::Install
Writing MYMETA.yml and MYMETA.json
Cannot find an extension with method 'write_meta' at lib/Module/Install/Admin.pm line 189.

File::Remove 1.42 has a download link. Next, I looked for Module::Build version 0.29 but didn't find it.

I understand if it's impossible or unfeasible to provide this specific version. Just wanted to investigate this route before trying other, more intensive attempts.

Apologies if this has already been addressed, or something I should take up with parent packages above. Just wanted to see if it were possible. Understandably, it's an older package and doesn't necessarily progress the latest version of this module, so may not be worth maintainer time.

If anything, leaving a marker for future folks searching past issues as well.

Thank-you,
Chris

Module::Build eval's in ExtUtils::CBuilder and doesn't propogate errors

In Module::Build::Base, there's this:

sub have_c_compiler {
  my ($self) = @_;

  my $p = $self->{properties};
  return $p->{_have_c_compiler} if defined $p->{_have_c_compiler};

  $self->log_verbose("Checking if compiler tools configured... ");
  my $b = eval { $self->cbuilder };
  my $have = $b && eval { $b->have_compiler };
  $self->log_verbose($have ? "ok.\n" : "failed.\n");
  return $p->{_have_c_compiler} = $have;
}

If ExtUtils::CBuilder fails to load for some reason, this will be reported back to the user as something like "You have no compiler....", even if they do, when the real issue is something wrong with the tool chain.

This should propagate errors up (possibly by just removing what might be a historical eval when CBuilder wasn't hard dep?)

Dropping 5.6 support?

In supporting utf-8 manpages, we seem to have accidentally dropped support of perl 5.6. Per Lancaster Consensus, that's perfectly ok (the new minimum is 5.8.1), but I think it should be a deliberate decision, not an accident of history.

So are we ok with this? And if so, does that mean we're cleaning up to 5.8 standards (we hadn't even finished cleaning up to 5.6 yet, IMO).

I'm fine with it, but @ribasushi suggested he was willing to make things work again on 5.6

Issue around PERL_UNSAFE_INC / dot_in_inc

0.42_23 added support for "dot-in-inc" in commit 5d94d41.
When I packaged 0.4224 for Debian, I therefore dropped our patch (the one mentioned in #69). The result is a build failure in libcatmandu-sru-perl. See the details and discussion in https://bugs.debian.org/865563 .

Our last thought was if the logic in the construction of the $dot_in_inc_code might be reversed, i.e:

--- /usr/share/perl5/Module/Build/Base.pm~    2017-06-19 17:25:18.000000000 +0000
+++ /usr/share/perl5/Module/Build/Base.pm     2017-06-23 17:42:01.820466942 +0000
@@ -1824,7 +1824,7 @@
   my $shebang = $self->_startperl;
   my $magic_number = $self->magic_number;

-my $dot_in_inc_code = $INC[-1] eq '.' ? <<'END' : '';
+my $dot_in_inc_code = $INC[-1] ne '.' ? <<'END' : '';
     if ($INC[-1] ne '.') {
         push @INC, '.';
     }

With this change in Base.pm, libcatmandu-sru-perl finds its test files again.

Thanks in advance for looking into this issue!

Cheers,
gregor, Debian Perl Team

typo re PERL_MM_USE_DEFAULT?

https://github.com/Perl-Toolchain-Gang/Module-Build/blob/master/lib/Module/Build/API.pod references PERL_MM_USE_DEFAULT a few times - shouldn't this be PERL_MB_USE_DEFAULT?

Remove wrapper modules

M::B::YAML and M::B::ModuleInfo are now just thin wrappers around the CPAN modules they were split off into. I would like to deprecate & then remove them.

I sent a note to the only person who depends on M::B::YAML: https://rt.cpan.org/Ticket/Display.html?id=86220

There are 2 distros that depend on M::B::ModuleInfo: https://metacpan.org/requires/module/Module::Build::ModuleInfo . I haven't contacted them.

Is the right way to deprecate just to stick a warn(...) in the body, and a notice in the docs?

bindoc extension not stripped

If I add bindoc_dirs => ['docs'], and put .pod or .pm files into docs/, resulting man1 file name will look like foo.pod.1 bar.pm.1

but for man3 pages in lib/ - extension .pod or .pm always stripped

How to specify prerequisites for the "develop" phase?

I understood with issue #31 M::B supports Meta 2.0, but I can't seem to specify requires for the "develop" phase. Adding "develop_requires" to Build.PL doesn't help as anything within it does not appear in META.json or META.yml. Is there a different way to do this or is it just not supported yet?

Should have sensible way for users/vendors to specify additional compile flags / override compiler from CLI

It is somewhat desirable for vendors and users alike to have a straightforward way of specifying overrides for executables, and supplementary flags to append to compilation ( such as cflags and ldflags ) which don't also conflict with those provided by perl itself, or conflict with those provided by the distribution itself.

The closest one presently gets is specifying --extra-compiler-flags and --extra-linker-flags on the commandline, but they can be impacted by the Build.PL itself.

Presently most the options a consumer has at their disposal either risks over-riding a sensible default just to extend it, or having their extension simply ignored.

This request is for something closer to what people experience in C land, where if a consumer specifies CFLAGS and LDFLAGS in their environment, the toolchain will tak those in at the right place without simply losing all existing configuration.

IRC Backstory:

06:58:01 <@kentnl> EUMM and MB Question: If a module is using this, https://metacpan.org/pod/ExtUtils::CppGuess # are there ways to override those guesses at the EUMM/MB level? ( ie: via ENV 
                   or invocations at install side ) or would that require patches to CppGuess to support such adjustment 
06:58:16 <+dipsy> [ ExtUtils::CppGuess - guess C++ compiler and flags - metacpan.org ] 
06:58:53 <@leont> Probably the latter
07:00:13 <@kentnl> it returns data to MB in the form of "extra_compiler|linker_flags"... but I have no idea what "extra" means here =)
07:03:01 <@leont> Those are really argument to ExtUtils::CBuilder
07:18:34 <@kentnl> leont: so if somebody did perl Build.PL --config "optimize= ... "  --config "lddlflags=... "  in the presence of CppGuess, would they get completely ignored?
07:19:22 <@leont> That should work
07:19:33 <@leont> But overriding lddlflags is something I'd recommend against
07:21:06 <@leont> It tends to contain important stuff
07:37:09 <@kentnl> So, imagine theres a XS based dist your code uses a lot of, and you want to squeeze out a few extra cycles by doing a profile-guided compile. This requires adding 
                   -fprofile-generate to both cflags and ldflags. How would you go about doing that without a) editing the .PL file by hand, or b) rebuilding perl itself ( or C) doing nasty 
                   shit with editing $Config ) ). 
07:37:52 <@kentnl> ( Also, I tried doing this with perl itself earlier in the week just for kicks, couldn't get it to build because it failed its own tests in ExtUtils::Constant for some 
                   reason I haven't dug into yet )
07:43:18 <@leont> In MB, --extra-compiler-flags and --extra-linker-flags would be the easiest way
07:44:12 <@kentnl> So I'm guessing the CppGuess just clobbers those parts eh.
07:45:38 <@leont> Kind of
07:46:06 <@leont> For MM it's also taking the obvious approach, but OTHERLDFLAGS is even harder to set from the outside
07:52:36 <@kentnl> so optimise= # is this extending or obliterrating the defaults?
07:54:41 <@leont> obliterrating, but at least in that field I wouldn't expect anything essential
07:54:56 <@leont> It's only passed on to the compilation stage, though
08:06:32 <@kentnl> so the overall vibe I get is "if you want to stick stuff in after dist-specified flags, there's presently no way of getting that to happen"  ( as oppossed to "what you're 
                   trying to do is too crazy and should never be done" )
08:07:10  * kentnl knows its a little crazy in the "probably viable but you get to keep the pieces" kind but thats acceptable for this context IME =)
08:13:08 <@leont> This is harder than it should be, yet
08:13:10 <@leont> yes
08:13:31 <@leont> It's also perfectly reasonable to want this, IMO

Motivation:

bgo #261375: dev-lang/perl and xs: bad CFLAGS and LDFLAGS handling
list of gentoo bugs pertaining to perl modules ignoring user specified flags
bgo # 233354: LDFLAGS used for Module-Build packages are LDFLAGS from dev-lang/perl

Module::Build should add itself to prereqs

MakeMaker adds this automatically to metadata (META.json):

   "prereqs" : {
      "configure" : {
         "requires" : {
            "ExtUtils::MakeMaker" : "0"
         }
      },
...

but Module::Build does not do something similar.

I believe Module::Build should add itself as a configure requires to META.json to make sure the Module::Build module is installed even before perl Build.PL is executed.

Module::Build tests take too long

When you install/upgrade Module::Build when it's a configure/build dependency for some modules, Module::Build tests usually take a lot of time. I tested it right now with the relatively new computer and it took 1 minute 40 seconds.

This is why I force notest flag in cpanm when it bootstraps Module::Build to the minimum version, so that the user's first experience feels a bit smoother.

i understand it is extremely important to test Module::Build and prevent a broken version from being installed, but when the tests take this long, it would lead people to run with --notest and that's a worse situation. I wonder if some chunk, or probably many, of the tests can be moved to release tests and automated testing (i.e. CPAN testers) only.

"Uninitialized value" warning in Module::Base::fix_shebang_line

With Module::Build 0.4216:

Running Build for A/AS/ASKSH/Snowball-Norwegian-1.2.tar.gz
Use of uninitialized value $line in chomp at /home/omengue/.plenv/versions/5.22.0/lib/perl5/site_perl/5.22.0/Module/Build/Base.pm line 3071.
Use of uninitialized value $line in substitution (s///) at /home/omengue/.plenv/versions/5.22.0/lib/perl5/site_perl/5.22.0/Module/Build/Base.pm line 3072.
Building Snowball-Norwegian
(./Build exited with 0)

Link to the source:

Module-Build/lib/Module/Build/Base.pm

Line 3071 in 6e53161

chomp(my $line = <$FIXIN>);

Module::Build fails install with perl 5.10.1, t/mymeta.t failure with meta-spec

I discovered this while trying to install cpanminus:

root@precise:~# perl --version

This is perl, v5.10.1 (*) built for x86_64-linux

Copyright 1987-2009, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

root@precise:~# curl -L http://cpanmin.us | perl - --sudo App::cpanminus
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   303    0   303    0     0    881      0 --:--:-- --:--:-- --:--:--  2089
100  262k  100  262k    0     0   548k      0 --:--:-- --:--:-- --:--:--  548k
--> Working on App::cpanminus
Fetching http://www.cpan.org/authors/id/M/MI/MIYAGAWA/App-cpanminus-1.7001.tar.gz ... OK
Configuring App-cpanminus-1.7001 ... OK
==> Found dependencies: Module::Build
--> Working on Module::Build
Fetching http://www.cpan.org/authors/id/L/LE/LEONT/Module-Build-0.4205.tar.gz ... OK
==> Found dependencies: Module::Build
Configuring Module-Build-0.4205 ... OK
Building and testing Module-Build-0.4205 ... FAIL
! Installing Module::Build failed. See /root/.cpanm/work/1394050418.20383/build.log for details. Retry with --force to force install it.
! Installing the dependencies failed: Installed version (0.340201) of Module::Build is not in range '0.36'
! Bailing out the installation for App-cpanminus-1.7001.

Examining the build log:

Test Summary Report
-------------------
t/mymeta.t                   (Wstat: 256 Tests: 39 Failed: 1)
  Failed test:  15
  Non-zero exit status: 1
Files=53, Tests=1132, 31 wallclock secs ( 0.19 usr  0.12 sys + 22.85 cusr  5.27 csys = 28.43 CPU)
Result: FAIL
Failed 1/53 test programs. 1/1132 subtests failed.
-> FAIL Installing Module::Build failed. See /root/.cpanm/work/1394037577.14688/build.log for details. Retry with --force to force install it.
-> FAIL Installing the dependencies failed: Installed version (0.340201) of Module::Build is not in range '0.36'
-> FAIL Bailing out the installation for App-cpanminus-1.7001.

More specifically Module::Build fails with meta-spec test:

#   Failed test 'Other generated MYMETA.json matches generated META.json'
#   at t/mymeta.t line 77.
#     Structures begin differing at:
#          $got->{meta-spec}{url} = 'https://metacpan.org/pod/CPAN::Meta::Spec'
#     $expected->{meta-spec}{url} = 'http://search.cpan.org/perldoc?CPAN::Meta::Spec'

testcover only works with Test::Harness, not TAP::Harness

The action testcover needs to set -MDevel::Cover when tests are executed, so that coverage metrics are collected. Currently, it tries to achieve this by these lines of code:
(https://github.com/Perl-Toolchain-Gang/Module-Build/blob/master/lib/Module/Build/Base.pm#L2805)

local $Test::Harness::switches    =
local $Test::Harness::Switches    =
local $ENV{HARNESS_PERL_SWITCHES} = "-MDevel::Cover";

This is broken in two ways:

Test::Harness::switches will be overwritten in run_test_harness, so setting it here has no effect whatsoever.
HARNESS_PERL_SWITCHES is only valued by Test::Harness, but not TAP::Harness.

The result is that testcover only works with Test::Harness:

$ rm -rf cover_db; ./Build testcover
...
Result: PASS
HTML output written to .../cover_db/coverage.html

but not in TAP::Harness:

$ rm -rf cover_db; ./Build testcover use_tap_harness=1
...
Result: PASS
Can't open database .../cover_db

IMHO, the correct way for testcover to work would be to add -MDevel::Cover to the harness_switches, as they are passed on correctly to both Test::Harness and TAP::Harness.

Seen on Gentoo Linux amd64, Perl 5.20.2 and Module::Build from git master, as well as 0.4214.

Generated man pages may not contain Unicode characters

Perl POD documentation may be encoded in UTF-8 encoding provided that an =encoding UTF-8 directive is present. The Pod::Man module is able to handle such documentation if the 'utf8' flag is set:

use Pod::Man;
my $parser = Pod::Man->new(section => 3, utf8 => 1);
$parser->parse_from_file('lib/MyModule.pm', 'mymodule.3');

As far as I can see, in Module::Build::Base#manify_lib_pods (https://github.com/Perl-Toolchain-Gang/Module-Build/blob/master/lib/Module/Build/Base.pm#L3268) it isn't possible to specify the encoding. Man pages produced from UTF-8-encoded POD documentation will thus always appear broken.

Does not support static linking

I can work around this like so (building Params::Validate in this example):

perl ./Build.PL --installdirs=vendor --config ldflags="-static" --config dlext="a"
./Build 2>/dev/null || true
ar cvr blib/arch/auto/Params/Validate/XS/XS.a lib/Params/Validate/XS.o
./Build

I dug into this a little bit and arrived at link_c (lib/Module/Build/Base.pm:5331) as the main place where changes would have to be made. I've never used Perl so some patience may be required as I examine this further.

[PATCH] Make Module::Build set PERL_UNSAFE_INC. (CVE-2016-1238)

In Debian we are currently applying the following patch to
Module-Build.
We thought you might be interested in it too.

From: Niko Tyni <[email protected]>
Date: Fri, 8 Jul 2016 15:55:37 +0200
Subject: [PATCH] Make Module::Build set PERL_UNSAFE_INC.

Cf. CVE-2016-1238

Author: Todd Rinaldo <[email protected]>
Origin: https://gist.githubusercontent.com/toddr/d77d8d5fa9caa8f96b7758a126caa4dc/raw/3b1a327efdd9a6babf5eed8fb9c241a6d4909be6/fix.patch

The patch is tracked in our Git repository at
https://anonscm.debian.org/cgit/pkg-perl/packages/libmodule-build-perl.git/plain/debian/patches/0004-Make-Module-Build-set-PERL_UNSAFE_INC.patch

Thanks for considering,
gregor herrmann,
Debian Perl Group

lib\Module\Build\Version.pm missing

I'm getting errors when trying to build Module::Build with cpanm. It can't seem to be able to find Version.pm and neither do I as it doesn't seem to be in the 0.4207 tarball

Building Module-Build

Failed test 'compiling lib/Module/Build/Compat.pm'

at t/00-compile.t line 15.

Can't locate Module/Build/Version.pm in @inc (@inc contains: /home/eps-remote/.cpanm/work/1408378918.20560/Module-Build-0.4207/blib/lib /home/eps-remote/.cpanm/work/1408378918.20560/Module-Build-0.4207/blib/arch t/lib t/bundled lib /var/arris/eps/perl5/perlbrew/perls/perl-5.8.9/lib/5.8.9/x86_64-linux /var/arris/eps/perl5/perlbrew/perls/perl-5.8.9/lib/5.8.9 /var/arris/eps/perl5/perlbrew/perls/perl-5.8.9/lib/site_perl/5.8.9/x86_64-linux /var/arris/eps/perl5/perlbrew/perls/perl-5.8.9/lib/site_perl/5.8.9 .) at lib/Module/Build/Compat.pm line 12.

BEGIN failed--compilation aborted at lib/Module/Build/Compat.pm line 12.

Looks like you failed 1 test of 21.

t/00-compile.t .................
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/21 subtests

Unshifting incorrect/old lib dirs onto @INC

I have been trying to install Convos, one of the deps is File::Remove, which uses Module::Build. I'm running this using the convos installer, which runs cpanm for each of the deps, which does its usual magic. Something was failing when installing File::Remove, as something was looking for an .so file in the wrong lib dir (in 5.30.3 dirs, not in 5.32 dirs)

NB: I had the same issue for some of the other dependencies, if I install them manually using cpanm on the command line, then they install .. via the script, they didn't. This one I decided to try and poke into why. (Until after various runs with debugging in Module::Build::Base, it did then magically install... )

Caveat - yes my perl -V has stuff in its @inc from previous versions, this is generally fine as perl reads them in order, and the old stuff is at the bottom. Why, I dunno, this is a gentoo system Perl.

perl -V:

  Built under linux
  Compiled at May 27 2021 16:13:00
  @INC:
    /etc/perl
    /usr/local/lib64/perl5/5.32/x86_64-linux-thread-multi
    /usr/local/lib64/perl5/5.32
    /usr/lib64/perl5/vendor_perl/5.32/x86_64-linux-thread-multi
    /usr/lib64/perl5/vendor_perl/5.32
    /usr/lib64/perl5/5.32/x86_64-linux-thread-multi
    /usr/lib64/perl5/5.32
    /usr/lib64/perl5/5.30.3
    /usr/lib64/perl5/vendor_perl/5.30.3
    /usr/local/lib64/perl5/5.30.3
    /usr/lib64/perl5/vendor_perl/5.30.1
    /usr/local/lib64/perl5/5.30.1
    /usr/lib64/perl5/vendor_perl/5.28.2

Error (with strace):

stat("/mnt/allthespace/usrsrc/extern/convos/local/lib/perl5/x86_64-linux-thread-multi/Encode.pmc", 0x7ffdfcc23620) = -1 ENOENT (No such file or directory)
stat("/mnt/allthespace/usrsrc/extern/convos/local/lib/perl5/x86_64-linux-thread-multi/Encode.pm", 0x7ffdfcc23620) = -1 ENOENT (No such file or directory)
stat("/mnt/allthespace/usrsrc/extern/convos/local/lib/perl5/Encode.pmc", 0x7ffdfcc23620) = -1 ENOENT (No such file or directory)
stat("/mnt/allthespace/usrsrc/extern/convos/local/lib/perl5/Encode.pm", 0x7ffdfcc23620) = -1 ENOENT (No such file or directory)
stat("/mnt/allthespace/usrsrc/extern/convos/lib/Encode.pmc", 0x7ffdfcc23620) = -1 ENOENT (No such file or directory)
stat("/mnt/allthespace/usrsrc/extern/convos/lib/Encode.pm", 0x7ffdfcc23620) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib64/perl5/5.30.3/x86_64-linux-thread-multi/Encode.pmc", 0x7ffdfcc23620) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib64/perl5/5.30.3/x86_64-linux-thread-multi/Encode.pm", {st_mode=S_IFREG|0444, st_size=32083, ...}) = 0
openat(AT_FDCWD, "/usr/local/lib64/perl5/5.30.3/x86_64-linux-thread-multi/Encode.pm", O_RDONLY|O_CLOEXEC) = 4
ioctl(4, TCGETS, 0x7ffdfcc233d0)        = -1 ENOTTY (Inappropriate ioctl for device)
lseek(4, 0, SEEK_CUR)                   = 0
read(4, "#\n# $Id: Encode.pm,v 3.06 2020/0"..., 8192) = 8192
stat("/usr/local/lib64/perl5/5.30.3/x86_64-linux-thread-multi/auto/Encode/Encode.so", {st_mode=S_IFREG|0555, st_size=54544, ...}) = 0
stat("/usr/local/lib64/perl5/5.30.3/x86_64-linux-thread-multi/auto/Encode/Encode.bs", 0x55ef5ed004b8) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/local/lib64/perl5/5.30.3/x86_64-linux-thread-multi/auto/Encode/Encode.so", O_RDONLY|O_CLOEXEC) = 5

Encode.c: loadable library and perl binaries are mismatched (got handshake key 0xcd00080, needed 0xed00080)

Assumption: this is because Module::Build unshifts some dirs onto @inc, one of them is the OLD dir for the Encode.pm/.so files:

  unshift @INC,
    (
     '/mnt/allthespace/usrsrc/extern/convos/local/lib/perl5/x86_64-linux-thread-multi',
     '/mnt/allthespace/usrsrc/extern/convos/local/lib/perl5',
     '/mnt/allthespace/usrsrc/extern/convos/lib',
     '/usr/local/lib64/perl5/5.30.3/x86_64-linux-thread-multi',
     '/usr/local/lib64/perl5/5.30.1/x86_64-linux-thread-multi'
    );

From I assume here:

Module-Build/lib/Module/Build/Base.pm

Lines 1821 to 1825 in b960411

 my @myINC = $self->_added_to_INC; 

 for (@myINC, values %q) { 

 $_ = File::Spec->canonpath( $_ ) unless $self->is_vmsish; 

 s/([\\\'])/\\$1/g; 

 }

Reading it (and dumping the @inc and the inc from _default_inc) (why would they be different!?) is as far as I got before the universe decided it would play after all...

There definitely is an Encode in the 5.32 dirs, it just doesn't get found first when using Module::Build (sometimes!) Makefile.PL based dists seem fine..

How to not install manpages a la EU::MM's INSTALLMAN3DIR=none?

I'm trying to trim down a darkpan install of modules, and on ExtUtils::MakeMaker, I can specify

export PERL_MM_OPT="INSTALL_BASE=/path/to/darkpan INSTALLMAN1DIR=none INSTALLMAN3DIR=none"

to prevent installing manpages. Is there a similar thing for Module::Build (and by extension, Module::Build::Tiny?)

I was looking into using --install_path bindoc=none --install_path libdoc=none, but it doesn't seem to work...

Cookbook typo

Hi!

There is a typo at this line in the Cookbook:

https://github.com/Perl-Toolchain-Gang/Module-Build/blob/master/lib/Module/Build/Cookbook.pm#L491

The closing backtick is missing.

PERL_MB_OPT should only apply to Build.PL command line

C.f. discussion in commit 886abd6

recommends now mapped to build_recommends?

Just apgraded to 0.42 and now I see that this config:

use 5.008008; # minumum perl version is 5.8.8, ancient cpan clients will ignore 'requires/perl' below
use strict;
use warnings;
use Module::Build;

my $build = Module::Build->new(
    module_name => 'App::MtAws',
    author => 'Victor Efimov <[email protected]>',
    dist_author => 'Victor Efimov <[email protected]>',
    dynamic_config => 1,
    recursive_test_files=>1,
    dist_abstract=>'mt-aws/glacier - Perl Multithreaded Multipart sync to Amazon Glacier',
    license     =>'gpl3',
    meta_merge => {
        resources => {
            repository => 'https://github.com/vsespb/mt-aws-glacier',
            bugtracker => 'https://github.com/vsespb/mt-aws-glacier/issues',
            homepage => 'http://mt-aws.com/'
        },
    },
    requires => {
        'perl' => 5.008008, # 5.8.8
        'LWP' => '5.803', # ancient CentOS 5.x version
    },
    build_requires => {
        'Test::Deep' => '0.092',
    },
    configure_requires => {
        'Module::Build' => 0.3,
    },
    recommends => {
        'LWP::Protocol::https' => 6,
    },
);

$build->create_build_script();

generates

   "prereqs" : {
      "build" : {
         "recommends" : {
            "LWP::Protocol::https" : "6"
         },
         "requires" : {
            "Test::Deep" : "0.092"
         }
      },
      "configure" : {
         "requires" : {
            "Module::Build" : "0.3"
         }
      },
      "runtime" : {
         "requires" : {
            "LWP" : "5.803",
            "perl" : "5.008008"
         }
      }
   },

why LWP::Protocol::https 6 is build recommends? previously it was runtime recommends ?

M::B 0.4202

Setting to clean existing distribution before installing

Problems: A distribution may remove files in a new version, but existing versions of those files are left on the user's system because the new distribution is just installed over the old one. Also, a distribution may be installed into a different directory (commonly sitearch->sitelib or vice versa) because it gains or loses an XS component.

Proposal: A setting the distribution author can enable in Module::Build which removes (only from the location where the distribution is to be installed to or the arch variant, if possible) the existing installation of the distribution, before the new distribution is installed. This would only occur if there is a packlist present. Similar to --uninst 1 but less "greedy" and the author can enable it rather than the user.

Potential issues: interaction with different @INC setups, installation locations, how to keep it "safe" under all these circumstances? are there any instances where core or vendor libs contain packlists?

Prior art: --uninst 1, https://metacpan.org/source/HAARG/Devel-GlobalDestruction-0.14/Makefile.PL#L62-75

Ref: Perl-Toolchain-Gang/ExtUtils-MakeMaker#325

Build.PL loses `develop.*` when generating MYMETA.json

When using Dist::Zilla, its pretty common for dists to ship with develop.requires in META.json.

It seems other metadata does get copied from META.json, just seems like prereqs is ignored in META.json and replaced, thus, the absence of develop.* in Build.PL means MYMETA.json has no develop_requires

This is not a serious dilemma , but annoying, as it means you can't simply do cpanm --with-develop --installdeps . on a build tree, because cpanm extracts deps from MYMETA.json.

Sure, cpanm could be adjusted to check META.json, but it seems more applicable to fix Module::Build here.

Especially seeing how small the difference is between META.json and the respective MYMETA.json is, namely, most differences are stringification, and the only notable differences are in repository. and prereqs.develop.

--- META.json   2013-10-21 00:27:08.208963123 +1300
+++ MYMETA.json 2013-10-21 00:39:12.919970919 +1300
@@ -4,7 +4,7 @@
       "Kent Fredric <[email protected]>"
    ],
    "dynamic_config" : 0,
-   "generated_by" : "Dist::Zilla version 4.300039, CPAN::Meta::Converter version 2.132830",
+   "generated_by" : "Module::Build version 0.4007, CPAN::Meta::Converter version 2.132830",
    "license" : [
       "perl_5"
    ],
@@ -24,21 +24,6 @@
             "Module::Build" : "0.4007"
          }
       },
-      "develop" : {
-         "requires" : {
-            "Dist::Zilla::PluginBundle::Author::KENTNL" : "2.000000",
-            "Pod::Coverage::TrustPod" : "0",
-            "Test::CPAN::Changes" : "0.19",
-            "Test::CPAN::Meta" : "0",
-            "Test::Kwalitee" : "1.12",
-            "Test::Pod" : "1.41",
-            "Test::Pod::Coverage" : "1.08",
-            "version" : "0.9901"
-         },
-         "suggests" : {
-            "Dist::Zilla::PluginBundle::Author::KENTNL::Lite" : "v1.3.0"
-         }
-      },
       "runtime" : {
          "requires" : {
             "Class::Tiny" : "0",
@@ -103,9 +88,7 @@
       },
       "homepage" : "https://github.com/kentfredric/Gentoo-Dependency-AST",
       "repository" : {
-         "type" : "git",
-         "url" : "https://github.com/kentfredric/Gentoo-Dependency-AST.git",
-         "web" : "https://github.com/kentfredric/Gentoo-Dependency-AST"
+         "url" : "https://github.com/kentfredric/Gentoo-Dependency-AST.git"
       }
    },
    "version" : "0.001000",
@@ -133,11 +116,11 @@
       },
       "perl" : {
          "original" : "v5.19.3",
-         "qv" : 1,
+         "qv" : "1",
          "version" : [
-            5,
-            19,
-            3
+            "5",
+            "19",
+            "3"
          ]
       },
       "perl-config" : {
@@ -524,4 +507,3 @@
    },
    "x_authority" : "cpan:KENTNL"
 }
-

module build fails ppm.t on windows

Yes I'm testing on windows. (Although I need a serious windows cleansing soon)

My intent is to install Dist:Zilla, when I do this, Module::Build fails a few tests and doesn't install.

I would love to send a pull request but I'll need someone to narrow the problem down a bit, or give me some clues to work with.

Some notes:

This test is on this line which happens to be after the __END__ statement. Forgive the newbie ignorance but is this normal?

Below is just the summary. Here is the build.log as a gist.

Test Summary Report
-------------------
t/ppm.t                      (Wstat: 256 Tests: 12 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
t/xs.t                       (Wstat: 1024 Tests: 22 Failed: 4)
  Failed tests:  3-6
  Non-zero exit status: 4
Files=52, Tests=1120, 208 wallclock secs ( 0.53 usr +  0.13 sys =  0.66 CPU)
Result: FAIL
Failed 2/52 test programs. 5/1120 subtests failed.

Fail to install

Module::Build may have dependency to inc::latest

In fact, I couldn't install this module with cpanm until installing inc::latest(I have read log with cpanm -v)

But according to source, Module::Build requires inc::[email protected] for 'inc_bundling_support'.

I don't know which but, it doesn't work or dismisses some dependencies.

Historically, inc::latest was forked from Module::Build but it seems to be dependent from Module::Build now.

just a way to solve this is to type cpanm inc::latest before cpanm Module::Build, but I will note it as an issue because there is no search result inc::latest from issue list.

Cannot install Module::Build on perl v5.8

Module::Build depends on Pod::Man,
and now Pod::Man (podlators distribution) requires perl v5.10.
https://metacpan.org/release/RRA/podlators-5.00

So we cannot install Module::Build on perl v5.8.

❯ perl -v
This is perl, v5.8.9 built for darwin-2level

❯ curl -fsSL https://cpanmin.us | perl - -nq Module::Build
Successfully installed ExtUtils-MakeMaker-7.64 (upgraded from 6.48)
Successfully installed version-0.9929
Successfully installed Module-Metadata-1.000037
Successfully installed JSON-PP-4.12 (upgraded from 2.27203)
Successfully installed CPAN-Meta-2.150010 (upgraded from 2.143240)
Successfully installed Perl-OSType-1.010
Successfully installed Locale-Maketext-Simple-0.21
Successfully installed Test-Simple-1.302191 (upgraded from 0.80)
Successfully installed Module-Load-0.36
Successfully installed Module-CoreList-5.20221120 (upgraded from 2.17)
Successfully installed Params-Check-0.38
Successfully installed Module-Load-Conditional-0.74
Successfully installed IPC-Cmd-1.04
Successfully installed ExtUtils-CBuilder-0.280236
Successfully installed ExtUtils-ParseXS-3.44 (upgraded from 2.19)
Successfully installed Pod-Escapes-1.07
Successfully installed Pod-Simple-3.43
! Installing the dependencies failed: Your Perl (5.008009) is not in the range '5.010'
! Bailing out the installation for podlators-5.00.
Successfully installed Test-Harness-3.44
! Installing the dependencies failed: Installed version (1.37) of Pod::Man is not in range '2.17'
! Bailing out the installation for Module-Build-0.4231.
18 distributions installed

HARNESS_PERL_SWITCHES no longer set so Devel::Cover spams child-parent comunication

As of commit fbe955b ( pull request #63, issue #62 ) the environment variable HARNESS_PERL_SWITCHES is no longer set to "-MDevel::Cover".

But Devel::Cover looks fot that being set and goes into silent mode if it is set.

If a unit test involves forking a child and the parent reading the standard output from the child, then Devel::Cover not being in silent mode means it spams the ouput from the child, the parent objects and the test fails.

It has taken two days of investigation into why a working unit test stoped working on upgrading.

Please reinstate the setting of the environment variable, or work with Devel::Cover developers to find another way to shut it up.

	my @myINC = $self->_added_to_INC;
	for (@myINC, values %q) {
	$_ = File::Spec->canonpath( $_ ) unless $self->is_vmsish;
	s/([\\\'])/\\$1/g;
	}