perl-toolchain-gang / cpan-api-buildpl Goto Github PK

This is a general CPAN client spec issue, not specific to Build.PL.

In the environment variable section something must be said about $ENV{PATH}: it must be consistent with @INC.

I'm writing this because some packages fail to install because the CPAN client has modified $ENV{PERL5LIB} to add some temporary lib paths, but did not modify PATH to add the bin or script dirs. This cause problems for distributions that rely on Perl scripts instead of modules, as we can get trouble if there is a mismatch between the script and its supporting modules (example: running an older script with the newer modules, or finding the module but not the newer script).

Here is an example issue: https://rt.cpan.org/Ticket/Display.html?id=75376

Currently, the document is sourced from two places: the first part is new, written by @dagolden (in wikidoc) and describes mostactions and arguments; the second part was written by Ken, and is a straight copy from Module::Build's docs. In particular, the workings of options is spread in a weird way.

How do we iron this out? Also with regards to some of the issues mentioned in #6.

Currently we have the --quiet option in the spec with a question mark behind it. I propose we drop it.

Firstly, having both verbose and quiet as separate entities is confusing,

Secondly, I don't see the use of it. What it currently does is in Module::Build

• Make file copying quiet
• Make fake installing quiet
• Make ExtUtils::CBuilder quiet
• Disable some informational output (e.g. "Building $distname\n"), unless verbose is also set.

It's not affecting TAP::Harness, despite that having lots of quietness levels.

I've often wanted a build to be more verbose, but I never wanted it to be more quiet. Maybe because CPAN clients can already make it quiet for me.

Module::Build accepts just about any argument convention under the rainbow in an unpleasantly heuristic and opportunistic manner. To be more precise it will accept any of:

1. verbose=1
2. --verbose
3. --verbose 1
4. --verbose=1
5. --no-verbose
6. --noverbose
7. --no_verbose

Getopt::Long (and other parsers AFAIK) can only parse some of those, in three different ways but never more than half at the same time.

1. As a boolean option (verbose!) it can parse 2, 5 and 6
2. As an integer option with mandatory argument (verbose=i) it can parse 3 and 4
3. As an integer option with an optional argument (verbose:1) it can parse 2, 3 and 4

Module::Build::Tiny does the last possibility currently, which I consider the most backwards compatible option as it makes the common styles 2 and 3 DWIM. Other than style 1 (which we don't support anyway), I don't think I've seen any of the others in the wild (5-7 would be silly anyway).

Should we add --extra-compiler-flags and --extra-linker-flags?

Module::Build and Module::Build::Tiny has a create_packlist option that defaults to true. This allows vendors to skip on the packlist, which a lot of packagers prefer to do.

Should we support that in the spec? Should we have something more high level? Do we even know what we need here?

Module::Build currently has two extra install actions: fake_install and pure_install.

The former is of somewhat limited use IMO unless you're writing a build system, but ExtUtils::Install has explicit support for it in the form of the dry_run argument.

The latter is more useful, as it guarantees that no perllocal is written. Currently in M::B, it's synonymous to install, though I'd like to change that in the future.

That said, this system is not scalable. Obviously, you can't combine fake and pure this way, and if we implement the install database we discussed in Lancaster this problem will only become worse.

Therefor, I propose we'll use flag arguments instead. e.g. ./Build install --fake --pure. That way we'll have plenty of space to grow in the future.

We live in a multi-core world. I'd like Build.PL to enable that in a sane way. Therefor I suggest we add a --jobs argument. This would be suggestion for the build tool to use a certain number of processes/threads when doing its job, similar to make -j.

Adding support for this in the testing phase is fairly easy (in both Module::Build and Module::Build::Tiny), and a future implementation may also implement it for other phases.

Should we add --config to the spec. This provides an escape-hatch to tweak various things, such the compilation process.

Should we specify the clean and realclean actions? They are useful, and some packagers (including debian) are (weakly?) depending on them. They shouldn't be too hard to define either.