Re: Ending Build.PL if there are missing modules
On Sun, Feb 5, 2012 at 1:15 AM, Eric Wilhelm wrote: >>It doesn't help with optional, dynamic prereqs so those have to be >>specified manually, but that's unavoidable I think. > > I've experimented with detecting those using my Devel::TraceDeps on the > running test suite. It is possible to see the source and target of > every require(), including failed ones (so you have to be using > eval+require, but you already knew it was incorrect to go stat()ing > around in @INC looking for your optional deps.) That's a different use case (though a neat trick). Seeing optional dependency load attempts is different than knowing which ones should be included in metadata (and whether they should be "recommends" or "suggests" or omitted) and what version of them are required. -- David
Re: Ending Build.PL if there are missing modules
On Sat, Feb 4, 2012 at 9:51 PM, Adam Kennedy wrote: > I was thinking about dropping anything without a specific numberic > version completely and requiring manual, because I figure the chances > for misidentification is too high (whereas a number will only really > be there after a human has put some specific thought into it). You're sort of talking about the equivalent of "use strict" for module importing. (Though note that it can't be done via C.) I think that's a sensible strategy, though I think you'll annoy people who really want it to DWIM rather than have to be explicit about it. -- David
Re: Ending Build.PL if there are missing modules
On Sat, Feb 4, 2012 at 9:43 PM, Adam Kennedy wrote: > If the goal is only to pick up versioned dependencies, I'm surprised > we even need to bother with that. It picks up as many "standard" dependencies as it can, but treats anything without a version as requesting version 0. -- David
Re: Ending Build.PL if there are missing modules
On Sat, Feb 4, 2012 at 5:17 PM, Adam Kennedy wrote: > That's how Module::Install's requires_from does it too. > > I should look at zilla's code and see how it runs, might be worth > aligning M:I and it's detection. It uses Ricardo's Perl::PrereqScanner, which does a pretty sane job of it (even detects base/parent and so on). It has some extensions for picking up Moose and POE prereqs and so on. It doesn't help with optional, dynamic prereqs so those have to be specified manually, but that's unavoidable I think. David
Re: Ending Build.PL if there are missing modules
On Sat, Feb 4, 2012 at 7:48 AM, Leon Timmermans wrote: > On Sat, Feb 4, 2012 at 1:32 AM, Adam Kennedy > wrote: >> While I agree it needs to finish, I do kind of wish dependencies could >> be enforced at the build module level so that tests couldn't run until >> dependencies are satisfied. > > I tend to agree with that. I've been writting Test::CheckDeps > (warning: very much a 0.001 release) to make it crap out as early as > possible during testing, but it could be even earlier. Plenty of code has dependencies listed that aren't truly required and tests will pass with lower versions. The proper way to enforce dependencies is in a "use" statement: use Foo::Bar 1.23; Not coincidentally, that's how Dist::Zilla detects dependencies, ensuring that code and specified prereqs are actually in sync. In my view, other tools are doing it wrong. -- David
Re: ExtUtils::MakeMaker question, before I post to a larger audience
On Wed, Dec 14, 2011 at 10:25 AM, Phil Kasten wrote: > I am using the cpan tool to install modules on a FreeBSD system that I do > not have root permission on. I have a provided a PREFIX for the makepl_arg, > to install everything in my local path. Almost everything works fine. There are two different sets of configuration options in the "cpan" tool, one for dists with Makefile.PL and one for dists with Build.PL. The options are separate because Makefile.PL and Build.PL have different argument names to do similar things. For "cpan" (i.e. CPAN.pm), the arguments are like this (type "o conf" from the cpan prompt to see them): makepl_arg make_arg make_install_arg Those are the arguments respectively for "perl Makefile.PL", "make" and "make install". Likewise, they have Build.PL equivalents: mbuildpl_arg mbuild_arg mbuild_install_arg Those are for "perl Build.PL", "./Build" and "./Build install" You need to set installation directory arguments for *both* makepl_arg and mbuildpl_arg. As others have mentioned, using INSTALL_BASE/install_base is recommended by experts over PREFIX. You should also explore the local::lib module on CPAN, which is designed to automate the kind of configuration that you're doing. See the "bootstrapping" documentation for how to set it up. https://metacpan.org/module/local::lib#The-bootstrapping-technique Good luck! -- David
New Module::Build patch/release manager
I'm very, very pleased to announce that Leon Timmermans has volunteered to be the new M::B patch/release manager and received his co-maint bit today. Leon has been working on abstracting the Build.PL API through his work on Module::Build::Tiny and has gotten very familiar with the guts of Module::Build as a result. He is also working to extract more of the reusable bits of Module::Build for other parts of the toolchain to reduce duplication. In my discussion with him about the role, he said that he is not planning on any major work to Module::Build, but has agreed to shepherd the future release process to ensure that his refactoring and other incremental changes are tested and released for CPAN and blead. Thank you very much, Leon! -- David
Official Module::Build repository has moved
To help spread the maintenance work further, I've created an "official" M::B repo in the "Perl-Toolchain-Gang" organization on github.com. (Thank you to Schwern for sponsoring this organization first with EU::MM.) https://github.com/Perl-Toolchain-Gang/Module-Build Please follow that repo instead of the dagolden one. At some point in the future, I'll be deleting my personal github repo entirely. If you are a regular patch submitter for M::B, please email me off-list about getting direct access. Thanks, David
Re: Possible bug?
On Tue, Oct 18, 2011 at 9:36 AM, Fields, Christopher J wrote: > https://github.com/bioperl/bioperl-network > > I can work on a minimal test case. If needed I can also fork the specific > github code and try to weed out the problem. No need to do the test case. I was able to load the bioperl dependency chain and see it directly. :-) I have two reactions: (a) Module::Build is doing it wrong -- in that it will "normalize" an undefined version to "0" and leave it in. The CPAN::Meta::Spec v2 says that the version metadata should only exist if a $VERSION string exists, but Module::Build does not produce v2 metadata and the v1.4 spec doesn't say anything about the subkeys of "provides". (b) PAUSE is being too nitpicky. An undefined $VERSION is effectively treated as a "0" in code, so it doesn't really matter too much if the metadata says "0" or omits the key. Nevertheless, in a battle between M::B and PAUSE, clearly PAUSE should win. (I get to wear both hats: I'm PAUSE admin *and* M::B co/ex-maintainer, so I'm indifferent.) I'll commit a fix to the repo and if/when a new M::B maintainer volunteers (or I'm forced by p5p to do another release), then it will go live. I do encourage adding $VERSION to the bioperl code (it looks like you're heading down the dzil route -- which can solve that for you). -- David
Re: Possible bug?
On Oct 18, 2011 3:39 AM, "Leon Timmermans" wrote: > > On Mon, Oct 17, 2011 at 5:08 AM, Fields, Christopher J > wrote: > > This appears to be due to the version for the modules being set to '0' in META.yml/json instead of not being defined (yes, we know this is a problem with the bioperl code, but Andreas indicated that lack of a module version probably should not default to '0'. Any reason this is occurring? > > Meta 2.0 is quite clear it should be absent if no version is detected. > Actually that is what Module::Build appears to be trying to do, I'm > not sure why it fails. Could we please get a minimal test case that demonstrates the error? Or even just a repo URL for the code in question? Thanks, David
Re: Nothing to enter for 'provides' field in metafile
On Wed, Mar 16, 2011 at 7:52 PM, Ron Savage wrote: > Hi Folks > > I've just started to get the warning msg in the Subject. > > I assume it's a side-effect of V 0.3800. > > I could not see any reference to a provides key in the docs for M::B, > nor via googling, altho I assume it goes in Build.PL somehow. It's generally provided automatically based on discovered package names. What dist is it? Is it a distribution with only scripts and no modules? -- David
Re: Time for a new Module::Build release manager
2011/3/7 Alberto Simões : > On 07/03/2011 19:34, John M. Gamble wrote: >> Well ... this raises a question. Whither Module::Build? >> >> Is its future simply to be the precursor to Dist::Zilla? Or to be wrapped >> up as a Dist::Zilla::Simple? > > AFAIK Dist::Zilla is NOT a substitute to Module::Build (or > ExtUtils::MakeMaker). That's correct. Dist::Zilla is a distribution packaging tool only. It *can* create a Makefile.PL or Build.PL for you (and most Dist::Zilla authors seem to do that) but your distribution still relies on EU::MM or M::B for the configure/make/test/install cycle for end-users. I wrote a little about which tools I think people should use here: http://www.dagolden.com/index.php/1173/what-tools-should-you-use-to-create-a-cpan-distribution/ I think M::B still has a role for customized distribution needs. -- David
Time for a new Module::Build release manager
Looking at BackPAN, my first Module::Build release was 0.33_01 in June, 2009. Here are some highlights of what has happened since then: * Over 60 Module::Build tarballs -- most of them development releases, admittedly * Converted the Module::Build from Subversion to Git, attracting a half-dozen or so new contributors * Rigorous triage of the M::B RT queue -- every ticket was reviewed to set the right severity and status * About 70 RT tickets noted in Changes * Updated release documentation and blead patching documentation Since then, my own use of Module::Build has declined, as much of my need for it as an author has been replaced by Dist::Zilla toolkit. At the same time, I've taken on additional responsibilities with P5P, CPAN PAUSE administration, and other parts of the toolchain. Therefore, with the release of 0.3800, I am retiring as Module::Build release manager. I will continue to contribute occasional patches, particularly relating to any bugs uncovered in the new CPAN Meta Spec v2 support added in 0.3800, but do not plan to release any more tarballs to CPAN, short of a major flaw in 0.3800 requiring an emergency fix. I encourage interested parties to speak up and volunteer to take on the release manager role. Regards, David Golden
Announcing Module::Build 0.3800
I'm pleased to announce the release of Module::Build 0.3800. It
should be appearing soon on a CPAN Mirror near you.
The major enhancement since the 0.36XX series is support for CPAN Meta
Spec version 2 files (MYMETA.json and META.json). Also, if you
haven't kept up with Module::Build, the 0.3607 release was nearly a
year ago and there have been over 20 development releases, mostly
fixing various bugs. An excerpt from the last year of Changes files
is included below.
-- David
### Module::Build Changes files since 0.3607 in April 2010 ###
0.3800 - Sat Mar 5 15:11:41 EST 2011
Summary of major changes since 0.3624:
[ENHANCEMENTS]
- Generates META.json and MYMETA.json consistent with version 2 of the
CPAN Meta Spec. [David Golden]
Also in this release:
[BUG FIXES]
- Autogenerated documentation no longer includes private actions from
Module::Build's own release subclass. [Report by Timothy Appnel,
fix by David Golden]
0.37_06 - Mon Feb 28 21:43:31 EST 2011
[BUG FIXES]
- prerequisites with the empty string instead of a version are
normalized to "0". (RT#65909)
[OTHER]
- More Pod typo/link fixes [Hongwen Qiu]
0.37_05 - Sat Feb 19 20:43:23 EST 2011
[BUG FIXES]
- fixes failing ppm.t in perl core
[OTHER]
- Pod typo fixes [Hongwen Qiu]
0.37_04 - Wed Feb 16 15:27:21 EST 2011
[OTHER]
- moved scripts/ to bin/ for less confusing porting to bleadperl
0.37_03 - Wed Feb 16 09:54:05 EST 2011
[BUG FIXES]
- removed an irrelevant test in t/actions/installdeps.t that was causing
failures on some Cygwin platforms
[OTHER]
- dropped configure_requires as some CPAN clients apparently get
confused by having things in both configure_requires and requires
- bumped Parse::CPAN::Meta build prereq to 1.4401
- bumped CPAN::Meta prereq to 2.110420
- Pod typo fixes [Hongwen Qiu]
0.37_02 - Mon Feb 7 21:05:30 EST 2011
[BUG FIXES]
- bumped CPAN::Meta prereq to 2.110390 to avoid a regression in 2.110360
0.37_01 - Thu Feb 3 03:44:38 EST 2011
[ENHANCEMENTS]
- Generates META.json and MYMETA.json consistent with version 2 of the
CPAN Meta Spec. [David Golden]
[BUG FIXES]
- t/signature.t now uses a mocked Module::Signature; this should be
more robust across platforms as it only needs to confirm that
Module::Build is calling Module::Signature when expected
[OTHER]
- Added CPAN::Meta and Parse::CPAN::Meta to prerequisites and dropped
CPAN::Meta::YAML
0.3624 - Thu Jan 27 11:38:39 EST 2011
- Fixed pod2html directory bugs and fixed creation of spurious blib
directory in core perl directory when running install.t (RT#63003)
[Chris Williams]
0.3623 - Wed Jan 26 17:45:30 EST 2011
- Fixed bugs involving bootstrapping configure_requires prerequisites
on older CPANPLUS clients or for either CPAN/CPANPLUS when using
the compatibility Makefile.PL
- Added diagnostic output when configure_requires are missing for
the benefit of users doing manual installation
0.3622 - Mon Jan 24 21:06:50 EST 2011
- No changes from 0.36_21
0.36_21 - Fri Jan 21 11:01:28 EST 2011
- Changed YAML::Tiny references to the new CPAN::Meta::YAML module
instead, which is the YAML-variant that is going into the Perl core
0.36_20 - Fri Dec 10 15:36:03 EST 2010
*** DEPRECATIONS ***
- Module::Build::Version has been deprecated. Module::Build now depends
directly upon version.pm. A pure-perl version has been bundled in inc/
solely for bootstrapping in case configure_requires is not supported.
M::B::Version remains as a wrapper around version.pm.
- Module::Build::ModuleInfo has been deprecated. Module::Build now
depends directly upon Module::Metadata (which is an extraction of
M::B::ModuleInfo intended for general reuse). A pure-perl version has
been bundled in inc/ solely for bootstrapping in case
configure_requires is not supported. M::B::ModuleInfo remains as a
wrapper around Module::Metadata.
- Module::Build::YAML has been deprecated. Module::Build now depends
directly upon YAML::Tiny. M::B::YAML remains as a subclass wrapper.
The YAML_support feature has been removed, as YAML is now an ordinary
dependency.
0.36_19 - Tue Dec 7 13:43:42 EST 2010
Bug fixes:
- Perl::OSType is declared as a 'configure_requires' dependency, but is
also bundled in inc (and loaded if needed) [David Golden]
0.36_18 - Mon Dec 6 16:46:49 EST 2010
Changes:
- Added dependency on Perl::OSType to refactor and centralize
management of OS type mapping [David Golden]
- When parsing a version number out of a file, any trailing alphabetical
characters will be dropped to avoid fatal errors when comparing version
numbers. These would have been dropped (with a warning) anyway during
an ordinary numeric comparison. (RT#56071) [David Golden]
Bug fixes:
- A Perl interpreter mismatch between runnin
Re: Action executed during configure
2011/1/26 Alberto Simões : > By the way, is there any standard way to "exit" or "die" from Build.PL if a > dependency (not a CPAN one, of course) is not met? Generally, just "exit 0 unless condition_satisfied". C.f. Devel::CheckLib -- David
Re: Looking to parameters to Build.PL
2011/1/26 Alberto Simões : > Hello > > Is there any easy way to peek the parameters added when run Build.PL? > > That is: > > perl Build.PL freeling_prefix=/my/strange/prefix Override "new", get the object from the SUPER::new and interrogate the object before returning it. Or override "cull_args" and inspect @ARGV before calling SUPER::cull_args, perhaps? Parameter processing is a complex given the potential for PERL_MB_OPT, .modulebuildrc files and command line arguments. -- David
Re: Action executed during configure
2011/1/26 Alberto Simões : > Hello > > Is there any action that I can subclass in mybuilder that is run during > "perl Build.PL" ? Not really. You can subclass "new" or any of the methods that it calls, of course. What are you trying to accomplish? -- David
Re: Campaign to reduce superfluous redundancies
On Sat, Dec 11, 2010 at 2:16 AM, Jonas B. Nielsen wrote: > Good work, > > Any plans to look at: Module::Build::ModuleInfo > > I think large parts could be replaced my Module::Info, well it is just a > hunch anyway mst has factored M::B::ModuleInfo into a separate Module::Metadata distribution and the latest dev M::B now relies on that. It might be possible to use another module, but then it's another module that has to go into core. I'm happier telling Jesse that the new module for core is just a refactored/renamed version of something already there. -- David
Campaign to reduce superfluous redundancies
As part of my campaign to eliminate redundancies, I've started on the following: * Deprecating Module::Build::ModuleInfo in favor of Module::Metadata, which mst extracted into its own dist so it could be used by EU:MM and other toolchain modules. * Deprecating Module::Build::Version in favor of relying directly on version.pm (which now is Makefile.PL only so we don't have a circular dependency) * Deprecating Module::Build::YAML in favor of YAML::Tiny, which is now approved by the pumpking to go into core perl This eliminates the need to continue copy/pasting things into the M::B distribution and avoids bugs due to mismatching versions of modules (which plagued M::B::Version particularly). In all cases, the dependencies are listed in 'configure_requires' and are bundled in inc/ if needed to allow a bootstrap on an older perl without configure_requires support. The M::B::* modules are being kept as empty subclass wrappers for now to ensure compatibility for anything else that was using them. In the coming weeks, I'll be asking people to test bootstrapping/upgrading the dev version, so please keep an eye out. If you have other ideas for eliminating redundancies, let me know. -- David
Re: Overcoming EU::MM's default behaviour for files ending with ".pl" in the module's root directory.
On Sat, Nov 20, 2010 at 5:11 AM, Shlomi Fish wrote: > I converted Config-IniFiles to create_makefile_pl => 'small' but I > wonder if there's some way to configure the Makefile.PLs generated by > 'traditional' to only process the modules under "./lib". You're welcome to submit a patch to RT. If the patch has tests, I'll probably apply it. That said, Module::Build::Compat is a very, very low priority. After Perl 5.14 is released and 5.10.1 is that last officially supported Perl, I don't see Module::Build::Compat as particularly useful anymore. David
Re: How to properly install Data Files
If you use a more recent Module::Build, look at the "share_dir"
parameter and File::ShareDir. That has been more widely tested than a
home-grown solution.
Regards,
David
On Mon, Oct 18, 2010 at 7:15 AM, Shlomi Fish wrote:
> Hi all,
>
> After I released a new version of XML-Grammar-Fortune-Synd, I got a lot of
> error reports from the CPAN testers:
>
> http://www.cpantesters.org/distro/X/XML-Grammar-Fortune-Synd.html
>
> The problem is that the data file installed by XML-Grammar-Fortune (its
> dependency) are not available for testing:
>
> http://search.cpan.org/dist/XML-Grammar-Fortune/
>
> So my question is: how can I install them properly? There's a repository for
> XML-Grammar-Fortune where you can see the Module-Build sub-class I used for
> that:
>
> http://svn.berlios.de/svnroot/repos/web-cpan/XML-Grammar-Fortune/trunk
>
> Currently I have:
>
> {{{
> package XML::Grammar::Builder;
>
> use strict;
> use warnings;
>
> use base 'Test::Run::Builder';
>
> use File::Find;
>
> our $VERSION = '0.0101';
>
> sub new
> {
> my $package = shift;
> my %args = @_;
> my @extradata_files;
>
> my $module_name = $args{'module_name'};
> $module_name =~ s{::}{-}g;
>
> my $filter_files_cb = sub {
> my $filename = $File::Find::name;
> if ((-f $filename) &&
> ($filename =~ /\.(?:mod|xslt|dtd|ent|cat|jpg|rng|xcf\.bz2)$/)
> )
> {
> push @extradata_files, $filename;
> }
> };
>
> find({ wanted => $filter_files_cb, no_chdir => 1}, "extradata");
>
> my $builder = $package->SUPER::new(
> extradata_files =>
> {
> (map { $_ => $_ } @extradata_files)
> },
> �...@_
> );
>
> $builder->add_build_element('extradata');
>
> $builder->install_path()->{'extradata'} =
> File::Spec->catdir(
> $builder->install_destination("lib"),
> qw(data modules),
> $module_name,
> qw(data)
> );
>
> $builder->config_data(
> 'extradata_install_path' =>
> [$builder->install_path()->{'extradata'}]
> );
>
> return $builder;
> }
>
>
> =begin excluded
>
> my $get_dest_extradata_cb = sub {
> my $fn = shift;
>
> # Trying if this makes it work.
> # TODO : Either remove this line or the rest of the lines.
> return $fn;
>
> $fn =~ s{^extradata}{data};
> return "lib/$module_name/$fn";
> };
>
> =end excluded
>
> =cut
>
> 1;
> }}}
>
> Regards,
>
> Shlomi Fish
>
> --
> -
> Shlomi Fish http://www.shlomifish.org/
> Apple Inc. is Evil - http://www.shlomifish.org/open-source/anti/apple/
>
> She's a hot chick. But she smokes.
> She can smoke as long as she's smokin'.
>
> Please reply to list if it's a mailing list post - http://shlom.in/reply .
>
Re: Adding script_files during... install
2010/6/14 Alberto Simões : > Unfortunately Build --debug is too laconic :) it just hows ACTION_code. > There isn't any way to force a more in-depth trace? Only the normal perl approaches. (e.g. "perl -D" with a debugging perl) (Though I'd welcome patches that improve the instrumentation using --debug) -- David
Re: Adding script_files during... install
2010/6/13 Alberto Simões :
> For windows, I need to create the .bat files, and I hope Module::Build
> does that automatically for script files.
It happens in make_executable which is called by process_script_files,
which is ultimately called by ACTION_code (I think).
If you run "Build --debug" on a recent M::B you should see a trace of
the actions called.
> So, my question is:
> - can I add script_files during the install action?
I don't see why not -- but you'd need to call $self->depends('code')
to get them built. Experimentation is necessary -- no guarantees it
will work. :-)
> - how can I set them? Not sure if I should use the scripts() method
> that seems to be deprecated.
You should be able to call $self->script_files(\%files), I think.
(You might want to retrieve the old hash and add to it first.) I
don't know why it's a hash. The values are ignored, I believe.
David
Re: Ignoring.. or controling Build install installbase=...
2010/6/12 Alberto Simões :
>> The main ACTION_install already depends on 'build', so all your
>> override of ACTION_install may need to do is to call
>> $self->depends_on("clean") if the path has changed and then call the
>> superclass method. (N.B. I haven't actually tried this approach.)
>
> Is there any problem on using a dispatch("build") during ACTION_install? :D
My thought was that it might find everything apparently "up to date"
and skip the actual re-build.
-- David
Re: Ignoring.. or controling Build install installbase=...
2010/6/12 Alberto Simões :
> I am using, during Build.PL first run,
> $builder->install_destination("bin");
>
> But, if the user issues a build install with a different installbase,
> things will not work.
>
> I have two options:
> 1) disable the installbase option to the Build install action
> 2) make the install action recompile everything again
>
> What is the more cleaner approach?
My thought is #2 by creating a subclass and overriding these two functions:
* ACTION_build -- use the notes() method to save the install path in
effect at compile time
* ACTION_install -- check if the install destination has changed and
rebuild if it has
The main ACTION_install already depends on 'build', so all your
override of ACTION_install may need to do is to call
$self->depends_on("clean") if the path has changed and then call the
superclass method. (N.B. I haven't actually tried this approach.)
-- David
Re: Installing dependencies
2010/6/8 Alberto Simões : > Hello > > Anybody can confirm this, from a module user, that was asking me to > include some build dependencies in the module tarball? > >> My motivation is asking this comes >> from the fact that not a few users had a problem similar to this one: >> > http://sourceforge.net/tracker/?func=detail&aid=2997821&group_id=228270&atid=1073792 >> because "./Build installdeps" does not take into account the builddeps >> of deps. This may actually be an issue with Module::Build itself. All "installdeps" does is fire up a CPAN client with a list of missing dependencies. Normally, that should resolve dependencies of dependencies. (Note that they may not have CPAN configured to install build dependencies.) If someone can provide a log of the output then maybe we can diagnose the "problem" better. Or have them install App::cpanminus and then try with "--cpan_client cpanm". That would help figure out of if it's a bug in CPAN or in Module::Build. -- David
Re: module::build, dist::zilla, and dealing with more than one module
On Thu, Jun 3, 2010 at 3:38 PM, Seth Daniel wrote: > I've been using Module::Build for several years. Typically subclassing > it to help build a module. I read with interest David Golden's blog post > about Dist::Zilla: > http://www.dagolden.com/index.php/752/why-im-using-distzilla/ > > It sounds as if Dist::Zilla can be used as a replacement for > Module::Build. In other words it can help build a single module. Since > David is the maintainer of Module::Build and is obviously a fan of > Dist::Zilla I was wondering on whether he would comment on the > practicality of migrating from subclassing Module::Build to using > Dist::Zilla. It's a replacement in the narrow sense of *packaging* a distribution. It doesn't replace Module;:Build (or ExtUtils;:MakeMaker) as an install tool. You still need a Build.PL or Makefile.PL in your distribution. However, if your Build.PL is pretty generic, Dist::Zilla can generated a Build.PL for you. If your M::B subclass is used for packaging, then Dist::Zilla may be able to replace that functionality in a more extensible way. If your subclass is used to customize the build or install process, then you'll still need that. (I believe that there was some recent work on Dist::Zilla to allow you put your subclass into inc/ and tell Dist::Zilla to use your subclass instead of Module::Build in the generated Build.PL) > In particular is it worthwhile for people who rarely need > to interact with CPAN? The code I write is almost entirely internal to > the comapny where I work. All of our modules are packaged and we don't > currently publish anything to CPAN. We find Module::Build adequate for > both development installation and in our build system for running tests > and creating packages (i.e. RPMs or debs). I would say that if it works for you, you probably don't need to change. Or, you may wish to use a subset of Dist::Zilla's features. For example, does your company mandate that all files have a copyright statement on them? If so, and if you don't want to keep them up to date, you could use Dist::Zilla for that. > On a somewhat related note is there anything out there that can help > with the building of multiple modules? Is Dist::Zilla good for this > too? As currently designed, I don't think it is. You might want to talk to some people who package Perl modules for Debian or FreeBSD as I think they have tools for doing some work in batch. Some of them hang out in #toolchain on irc.perl.org. > I am particulary interested in anything that can take a list of > module directories (e.g. Foo-A/, Foo-B/, Foo-B-Z/), run the tests, and, > assuming everything is okay, come back with RPMs of said modules. It > would need to do this in the proper order (preferrably automatically > discovering dependencies). It seems I always have to build something to > do this wherever I go and it gets tiresome. You might want to look at PAR or FatPacker, but neither of those are quite what you describe. -- David
Re: testcover and tap_harness_args
If you could please send me a new patch (or a git pull request), I'll
apply it to the repo.
Thanks,
David
On Thu, May 27, 2010 at 10:11 PM, Elliot Shank wrote:
> On 5/27/10 2:37 PM, Eric Wilhelm wrote:
>>
>> # from Elliot Shank
>> # on Thursday 27 May 2010 05:46:
>>
>>> it uses Storable, which wasn't in core until 5.7.3
>>
>>> + $tap_harness_args = dclone($tap_harness_args);
>>> + $orig_tap_harness_args = dclone($tap_harness_args);
>>> + my $switches = $tap_harness_args->{switches} || [];
>>> + push @{$switches}, '-MDevel::Cover';
>>> + $tap_harness_args->{switches} = $switches;
>>
>> $orig_th_args = {%$th_args};
>> $th_args->{switches} =
>> �...@{$th_args->{switches}||[]}, '-MDevel::Cover'];
>
> Aha. Yeah, depth two copy is enough.
>
Re: How do I remove something from provides?
On Sat, May 1, 2010 at 9:23 PM, Michael G Schwern wrote: > I say no_index should influence the generation of provides, yes? +1 The new CPAN::Meta package has methods for determining if particular packages should be indexed or not given a no_index. As we convert M::B to use CPAN::Meta, we should make sure that provides and no_index are harmonized. -- David
Re: How do I remove something from provides?
On Sat, May 1, 2010 at 2:12 PM, Michael G Schwern wrote:
> I've just written Object-ID which contains UNIVERSAL::Object::ID. This
> contains the code:
>
> package UNIVERSAL;
> use Object::ID;
>
> Module::Build sees that and adds UNIVERSAL to the provides info in META.yml.
> Ok, I don't really want to say that I provide UNIVERSAL. I add no_index => {
> package => ["UNIVERSAL"] } to my MB arguments and rerun distmeta. UNIVERSAL
> still shows up in provides.
>
> What's the proper way to remove something from the provides metadata without
> having to rewrite the whole thing?
I think it's the usual two-line trick:
package # hide from provides
UNIVERSAL;
-- David
Re: MANIFEST.SKIP deleted on distclean?
On Fri, Apr 16, 2010 at 10:11 PM, Eric Wilhelm wrote: > Dancing around some old clunky code that just looks like a pile of > monkey patches swinging from a tree of assumptions is a lot more > maintainable than a pile of monkey patches to make it take input via > variables instead of the filesystem? Dist::Zilla (No MANIFEST or MANIFEST.SKIP required) -- David
Re: Repository commit notifications?
On Fri, Apr 16, 2010 at 6:01 PM, Curtis Jewell wrote: > I'd like to see, at a minimum, a Twitter feed and some sort of IRC > notification. After that, hmmm... What IRC channel? #toolchain? Something more specific to Module::Build? -- David
Re: MANIFEST.SKIP deleted on distclean?
Pushed to the repo the following changes: * When generating MANIFEST.SKIP for distcheck, it will be removed immediately when the action is completed. (This means that subsequently added MANIFEST.SKIP will not be deleted during "clean".) * Added "Build manifest_skip" to generate one permanently if desired -- David
Repository commit notifications?
Now that Module-Build has migrated to git and is hosted on github, there are several options for post-commit hooks to post commits to various channels. Here's a list of what's available: * Post-Receive URLs (0) * Basecamp * CIA * Campfire * Email * FogBugz * Freckle * FriendFeed * Irc * Jabber * Lighthouse * Presently * Rdocinfo * Rubyforge * RunCodeRun * Statusnet * Talker * Trac * Twitter * WebTranslateIt Any thoughts or preferences? -- David
Re: MANIFEST.SKIP deleted on distclean?
I'm looking to see if we can make the generated one temporary easily.
David
On Fri, Apr 16, 2010 at 10:53 AM, Curtis Jewell
wrote:
>> And if people really need a skeleton MANIFEST.SKIP, we can add "Build
>> manifest_skip" to generate a default one (that then persists)
>>
>> -- David
>
> Easy enough. Practically a one-liner.
>
> sub ACTION_manifest_skip {
>
> if (not -e 'MANIFEST.SKIP') {
> # I'm assuming we're already in the right directory.
> open $skipfile, '>', 'MANIFEST.SKIP';
> print {$skipfile} "#!include_default\n"; # See
>
> http://search.cpan.org/~rkobes/ExtUtils-Manifest-1.58/lib/ExtUtils/Manifest.pm#MANIFEST.SKIP
> close $skipfile;
> }
> }
>
> --
> Curtis Jewell
> csjew...@cpan.org http://csjewell.dreamwidth.org/
> p...@csjewell.fastmail.us http://csjewell.comyr.org/perl/
>
> "Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c
>
> Strawberry Perl for Windows betas: http://strawberryperl.com/beta/
>
>
Re: MANIFEST.SKIP deleted on distclean?
On Fri, Apr 16, 2010 at 1:47 PM, Eric Wilhelm wrote:
> Or, dirty hacks:
>
> my $orig = \&ExtUtils::Manifest::maniskip;
> local *ExtUtils::Manifest::maniskip = sub {
-1
Dirty hacks lead to maintenance headaches later.
I'd rather not clean up the MANIFEST.SKIP before monkeypatching things.
David
Re: MANIFEST.SKIP deleted on distclean?
On Fri, Apr 16, 2010 at 9:54 AM, Zefram wrote: > That would piss me off. I don't use MANIFEST.SKIP files: I maintain > the MANIFEST manually. If M:B really needs a MANIFEST.SKIP to exist, > for its internal use, then that is a temporary build file and must be > cleaned up no later than "./Build distclean". If it doesn't clean it up, > then it's polluting *my* directory. > > Actually, there's another problem. If it doesn't clean up the generated > MANIFEST.SKIP, then late in "./Build distclean" it notices that this > file isn't listed in MANIFEST and complains. (That is, it isn't listed > if you don't use a MANIFEST.SKIP file, which was the situation requiring > it to be generated in the first place.) Do you realize that "distclean" is "realclean" plus "distcheck"? > I fail to see why M:B needs a MANIFEST.SKIP when it is not being called > upon to generate a MANIFEST. "distcheck" needs to know what to skip. Some modern ExtUtils::Manifest have a pretty good default. Older ones don't. I'm wondering if the "answer" is to generate MANIFEST.SKIP for the duration of distcheck and related activities *only* and not let it hang around all the way to be cleaned later. That would avoid all the confusion, I think. And if people really need a skeleton MANIFEST.SKIP, we can add "Build manifest_skip" to generate a default one (that then persists) -- David
Re: MANIFEST.SKIP deleted on distclean?
On Thu, Apr 15, 2010 at 4:57 AM, Steffen Schwigon wrote: > Hi! > > I did not expect that my MANIFEST.SKIP file (either self-written or > auto-generated) gets deleted during ./Build distclean. > > What is the rationale behind that? > I couldn't read that out of the documentation. The only reason MANIFEST.SKIP should be deleted is if Module::Build created it because you didn't have one. In that case, it would actually get removed with "Build clean" (which distclean calls). There is a subtle wrinkle that the cleanup list that "Build clean" uses is persistent until distclean or realclean. So you need to run 'Build realclean', then create your MANIFEST.SKIP, then run 'perl Build.PL', etc. as normal. -- David
Re: [rt.cpan.org #53478] Diffs with ActiveState HTML generation and PPM compatibility
On Wed, Apr 14, 2010 at 2:25 AM, Klaus Eichner via RT wrote: > Now that Perl 5.12 is out, > can we discuss the changes to Module::Build::Base (and a new module > ActivePerl::PPM::InstallHist) ? as per the attachment -- two files > 'Base.36032.pm' and 'InstallHist.00100.pm' -- in my message from 10 Feb > 2010. We can try. Since your patch, Module::Build has migrated to git and is being hosted at github. http://github.com/dagolden/module-build/ I have created a branch 'rt/53478' with your patch: http://github.com/dagolden/module-build/tree/rt/53478 It fails t/ppm.t because that test expects HTML files and the patch stops them from being produced. (Intentionally). I'm not sure if that is the right thing, since it may impact non-ActiveState users of PPM. Now that we have git for easy branching, I encourage more refinements for that branch including getting all tests to a passing state. If no one on the M::B mailing list objects to PPM no longer having HTML generated for them, or has an alternate solution that gets consensus, I'd be happy to merge the branch into the main line. Regards, David
Module-Build repository migrated to git
I have completed a migration of the Module::Build repository from Subversion to git. The new repository is available publicly on github.com: * browse it: http://github.com/dagolden/module-build/ * clone it: git://github.com/dagolden/module-build.git I have done my best to clean up the merge/branch/tag history, but have not bothered to clean up empty commits left over from the original cvs2svn conversion. If anyone sees any glaring errors please let me know. I have also implemented a rudimentary "Build upload" action in the custom inc/ModuleBuildBuilder.pm subclass. Until something better comes along, this supersedes previous release tools. I hope this migration makes it easy for people to contribute to Module-Build. At the very least, it will make working on feature branches much easier to manage. I will be "closing out" the SVN repository with a pointer to the new location shortly. Regards, David
Re: Adding both mozilla1.0 and mozilla1.1 to the list of licenses
On Sat, Mar 27, 2010 at 7:45 AM, Gabor Szabo wrote: > That's what I did but I expect some arguments from the core Bugzilla > developers > and their lawyers. I'll use your point if needed. Thanks The license field in Module::Build just sets the same field in META.yml. If they don't like 'mozilla' (generic) set it to 'open_source', which is the option for "META.yml spec doesn't support what I really want to put here". You still must document the actual license terms in the code you release. -- David
Re: Adding both mozilla1.0 and mozilla1.1 to the list of licenses
On Sat, Mar 27, 2010 at 7:25 AM, Gabor Szabo wrote: > I am now trying to get Bugzilla packaged to CPAN and it is explicitely > licensed > under mozilla1.1 > > Would it be possible to add those two keys to the valid list of values > of the license field? > Software::License http://search.cpan.org/dist/Software-License/ > already has them separated. Hi, Gabor. Just list it as "mozilla" or "open_source" for now. The way licenses get handled will be revised when we release the CPAN Meta 2.0 spec later this year. (And both Mozilla licenses are already included separately in the valid list in the draft 2.0 spec). -- David
Re: dependencies with Build.PL files
On Tue, Feb 23, 2010 at 6:54 PM, Eric Wilhelm wrote: > We've run into a Build.PL vs Makefile.PL problem with cpanminus. The > situation is that if M::B requires anything with a Build.PL file, that > it becomes impossible to bootstrap. We should remove Build.PL from anything that M::B requires. That has already been done for EU::CBuilder and needs to be done for EU::ParseXS. > The easy thing would be to remove the Build.PL from ExtUtils::ParseXS, > ExtUtils::CBuilder, etc (but only because we have comaint on those.) We know who the maintainers are and can encourage them. Test::Harness is already done. EU::Install probably should be changed, too. > Slightly more difficult would be to remove them from our 'requires' > (since they are not strictly required) and insert them in > build_requires as needed (in META.yml and MYMETA.yml). I think this > would actually be more correct. David, what was the logic for these > recent additions to 'requires'? The logic was that installation of M::B should ensure a "sane" toolchain, where "sane" is defined by me to mean "recent enough to have substantial numbers of bugs fixed". > We went back and forth about a few possible workarounds in #toolchain, > but those all get thrown out because a client should not assume that > Build.PL uses Module::Build. Agreed. E.g. my "in-development" Acme::Module::Build::Tiny to prototype exactly what a minimal "Build.PL" and "Build" API should be. > So, if -e "Build.PL", a cpan client should only ever need to do: > > 1. satisfy configure_requires > 2. run Build.PL > > If we break that, we've created a bug in M::B. Agreed. David
Re: MYMETA.yml vs. the default MANIFEST.SKIP
On Tue, Feb 23, 2010 at 12:44 PM, Eric Wilhelm wrote: > So, the default MANIFEST.SKIP should contain MYMETA.yml? M::B does and the latest ExtUtils::Manifest does. But a MANIFEST.SKIP is only created for "Build manifest" or "Build distcheck", so it doesn't help during disttest. More likely, distdir should check that MANIFEST.SKIP is not skipped and complain violently (or just fix it). (Patches welcome.) David
Re: MYMETA.yml vs. SIGNATURE
I'm going to step *way* back in this discussion. I've been able to
replicate the issue, which is the first step to finding a thoughtful
resolution:
(1) All prerequisites to actually run the signature test file are
satisfied. (E.g. $ENV{TEST_SIGNATURE}, etc.
(2) MANIFEST.SKIP is in MANIFEST.SKIP and thus not added to MANIFEST
or copied to the distdir (where the signature test is actually run)
(3) ExtUtils::Manifest version prior to 1.58
(4) Run: "perl Build.PL", "./Build disttest"
Thus, two solutions immediately present themselves:
(a) Do *not* skip MANIFEST.SKIP. This ensures that it winds up in
distdir (including the explicit skip of MYMETA.yml).
(b) Upgrade ExtUtils::Manifest to 1.58 (which includes MYMETA among
the default skip list when no MANIFEST.SKIP exists)
Both solutions work independently. I recommend doing both of them, on
the off chance that some end user just happens to have set
TEST_SIGNATURE and has a old version of ExtUtils::Manifest.
-- David
Re: MYMETA.yml vs. MANIFEST.SKIP
On Tue, Feb 23, 2010 at 1:04 AM, Michael G Schwern wrote: >>> I think Eric was asking why Module::Signature isn't ignoring MYMETA >>> once it gets added to MANIFEST.SKIP. >> >> Yeah. If Module::Signature is just being naïve, then I guess that's not >> our problem. > > I don't think its naïve to trust the MANIFEST, having it second-guess would > probably cause more trouble. > > Anyhow, agreed that this is a transient problem that happens once per dist > and will clear up as soon as the author rebuilds the MANIFEST. After sleeping on it, here's my (untested) hypothesis. If MANIFEST.SKIP is *in* MANIFEST.SKIP, then a "disttest" will create a distdir with no MANIFEST.SKIP and a SIGNATURE that reflects that. Then, when Build.PL is run in the distdir, it creates a default MANIFEST.SKIP and then problems ensue. -- David
Re: MYMETA.yml vs. MANIFEST.SKIP
On Mon, Feb 22, 2010 at 10:36 PM, Michael G Schwern wrote: > Eric Wilhelm wrote: >>> >>> $master:~/cpan/perlids>./Build disttest >>> Creating Makefile.PL >>> Creating META.yml >>> *File 'MANIFEST.SKIP' does not include 'MYMETA.yml'. Adding it now.* >>> ... >>> *t/00-signature.t . Not in MANIFEST: MYMETA.yml >>> ==> MISMATCHED content between MANIFEST and distribution files! <==* >> >> I agree with Adam and Michael on what you should do here. >> >> But I'm curious about how the automatic addition of MYMETA.yml to >> MANIFEST.SKIP (as shown in the output) didn't keep you from running into >> this. (I'm mostly concerned about whether it might cause problems for more >> valid use-cases than a signature.t.) > > Adding MYMETA to MANIFEST.SKIP does not cause the MANIFEST to be rebuilt. I think Eric was asking why Module::Signature isn't ignoring MYMETA once it gets added to MANIFEST.SKIP. -- David
Re: Proper technique for setting a project-wide $VERSION?
On Fri, Feb 19, 2010 at 4:14 PM, Michael G Schwern wrote: > Hi, > I want to set a $VERSION for my whole project, same in every .pm file. I > used to just use a script that did some s/// but its gotten a bit more > complicated now that I'm using version.pm. Is *not* using version.pm an option? > A simple fix would seem to be putting "use lib 'lib'" into the Build.PL. > Any caveats. Alternatively, anyone have a better way? I'd probably just write another script to do s///. Should be easy, since not many lines will start "use version 0.77;..." -- David
Re: Changing the way tests are run
2010/2/18 Alberto Simões :
> So, if I change this variable when calling Test::Harness everything
> should work fine.
>
> Is there any easy way to force this under M::B?
Subclass and override ACTION_test
sub ACTION_test {
my $self = shift;
# do %ENV manipulation
$self->SUPER::ACTION_test
}
In general, most custom things you might want to do should get done in
a subclass that override ACTION_* steps.
-- David
Re: Making files executable
2010/2/16 Alberto Simões : > Interested in a patch to add bin_files to Module::Build? > (not sure if I will be able to write it but I offer to try...) I'd discuss the logic on the list first. On the one hand, I like it, but on the other hand, explaining that "script_files" means the "bin/" directory that installs to "installsitescript", but "bin_files" aren't in "bin/" but install to "installsitebin" seems awfully confusing. -- David
Re: Making files executable
2010/2/16 Alberto Simões :
> OK, because there isn't a $builder->binary_files option or a
> $builder->executable_files option :P
Long, sordid history here. This is more or less correct as a summary of it:
* Used to have a 'scripts' property that defaulted to the 'scripts'
directory in the distribution directory
* 'scripts' property was renamed to 'script_files'
* 'script_files' changed to default to 'bin' directory in the
distribution directory
* 'script_files' contents copied to blib/script
* things in blib/script installed to a location depending on
installdirs or install_base:
'core' => $Config{installscript}
'site' => $Config{installsitescript} || $Config{installsitebin} ||
$Config{installscript}
'vendor' => $Config{installvendorscript} ||
$Config{installvendorbin} || $Config{installscript}
or for install_base => "$installbase/bin"
Clear as mud, right?
So what you need to do is probably follow the "Adding new file types
to the build process" recipe in the Module::Build::Cookbook and add a
"bin" type with a process_bin_files that puts things in blib/bin --
then you'll get whatever default installdirs/install_base behavior is
normal for "bin" type files. E.g. $Config{installsitebin}
-- David
Re: When was the "use lib" bug fixed?
On Sun, Feb 14, 2010 at 8:47 PM, Michael G Schwern wrote: > This has worked for some time, "inc" gets added to ./Build. But it appears > not to with certain versions of Module::Build, I'm trying to track down > what. Build can't find Local::Module::Build, its not in its @INC. > > Any idea when this bug was fixed so I can add in the proper MB dependency? It was fixed in 0.36: - resume() was not restoring additions to @INC added in Build.PL (RT#50145) [David Golden] N.B. If you build your dist with M::B 0.35+, don't already have M::B in configure_requires and don't explicitly turn *off* auto_configure_requires, you will automatically get the last "major" version of M::B added as a configure_requires. -- David
Re: [PATCH] EU::CBuilder compile supporting include_dirs as a string
Alberto -- could you please send patches to the M::B RT queue? I've been using that aggressively to triage and stage issues and it's very helpful to make sure things don't get lost. I'm very supportive of your changes, but I'm only doing critical M::B patches at the moment as I'm very overloaded with other projects with tight deadlines. If Eric or others want to commit your patches, that's great too, but I'm not going to have a chance to review things until March at the earliest. David 2010/2/13 Alberto Simões : > Hey David, hi MB fans, > > Accordingly with the documentation, ExtUtils::CBuilder compile method > support 'include_dirs' as > > Specifies any additional directories in which to search for header > files. May be given as a string indicating a single directory, or > as a list reference indicating multiple directories. > > But in latest version a string is not allowed. > > Patch fixes that. > > Cheers > Alberto > > -- > Alberto Simões >
Re: Help building a C library
2010/2/12 Alberto Simões : > Hello > > Before, the question (later the history): I need to compile a library > that is pure C. I would like this process to be the more portable > possible (strawberry Perl is one of my targets). > > Later, this library will be used to: > - be linked with some extra C code and build some binaries > - be linked with a XS file to interface with the Perl Module. > > Anybody can give me some hints on where to look at? I am looking at > Module::Build::API but not sure if I will be able to accomplish my needs > just looking there :) I have very little experience what what you describe, but I know the M::B API reasonable well. :-) I'd suggest seeing how far the "c_source" parameter gets you. http://search.cpan.org/~dagolden/Module-Build-0.3603/lib/Module/Build/API.pod#c_source Best of luck. When you're done, if you can write up the process into a cookbook entry, I'd love to include it in the official Module::Build documentation. -- David
Re: Bug Tracker #53478 and HTML documentation
Scott -- that sounds like a great analysis and bit of work. I'm not doing any non-critical M::B patching at the moment, so could you please add your comments and patch to the RT#53478 ticket so it doesn't get lost? Thanks, David On Tue, Jan 26, 2010 at 8:27 PM, Scott Renner wrote: > Hello, > > > > I recently encountered a problem with the tarballs generated by > Module::Build reported a bug a few weeks ago. I got a mail the next > morning that it had recently been fixed. Thanks!!! > > > > I noticed bug #53478 “Diffs with Active State HTML generation and PPM > compatibility” because I am working on a utility to fix broken links in the > HTML documentation that are caused by a variety of reasons (mostly due to > pod2html inability to figure out links correctly.) Anyway, I have become > very familiar with ActiveState HTML generation routines (and pod2html) and > have come up with fixes for Module::Build that will address all of the HTML > generation issues, including the generation of the Table of Contents on > ActivePerl installations. > > > > The fixes are pretty simple and I’ve attached Module::Build::Base.pm with my > the changes. The changes are based on build 0.3603, with a new version of > 0.36031. > > > > I’ve tested quite a bit (doing a variety builds, install, ppminstall, dist, > ppmdist, etc.) and everything works as it should, but I am limited to > Windows for testing. I’ve tested on Perl 5.8 and 5.10 (both AS and > standard). > > > > With these updates, there is no need to make changes to EU:Install to get > the html documentation working properly on any type of installation. > > > > Here is a summary of the changes…. > > > > In the section setting default properties… (line 929) > > > > Deleted the property “html_css”, it is no longer needed or used. > > > > sub _is_ActivePerl (line 3034) > > > > New method that returns true if running on an ActivePerl installation. Is > set using the same eval (require ActivePerl::DocTools) that was used to set > the property “html_css”. This is not a property because its value needs > to be determined when the installation is run, not the value on the system > that built the package. > > > > sub ACTION_manpages (line 3039) > > > > I removed the check to see if there are any files to process, because this > is performed in both the ‘manify’ subs. No point in doing the check twice. > > > > sub ACTION_html (line 3133) > > > > I also optimized this sub as well. ‘htmlify_pods’ checks if there are no > files to process, so there really isn’t any point in doing the check here > too. > > > > Sub htmlify_pods (line 3172) > > > > I saw the comment that says “Links to other modules are not being generated” > and saw the problem. The original code uses “$self->blib” as the “podroot” > and “podpath” only points to directories in “blib”. “podroot” must be the > absolute path to the directory where the installed pod files are stored, and > “podpath” can be relative directories off of podroot, plus an absolute path > to the “blib” directory. With this code, all links are generated > properly. > > > > If $self->_is_ActivePerl is true, we use ActivePerl::DocTools::Pod::pod2html > to generate the HTML documentation, otherwise we use Pod::Html:pod2html to > create it. The ActivePerl version also uses Pod::Html::pod2html, but then > does some post processing on the HTML files to format them in the ActivePerl > style. > > > > I also added code to do some cleanup on the html files after they are > generated by pod2html. The generated HTML is NOT XHMTL, so the DOCTYPE is > wrong. IE6+ will not display the page if it does not pass validation based > on the DOCTYPE. Local pages also need this statement in the “” for IE6+ to load local html > pages (file://) if certain security settings on the user’s PC are strict. > Lastly anchor references to html pages within the package point to the > “blib” directory. These are fixed up so they point to where they will be > after they are installed. > > > > sub ACTION_install (line 3357) > > > > Added logic to check if ‘$self->is_ActivePerl’ is true, and run > ActivePerl::DocTools::WriteTOC(). WriteTOC() is the ActivePerl routine that > updates the ActivePerl Table of Contents page and must be run AFTER the all > the html files have been installed. > > > > sub ACTION_ppmdist (line 3515) > > > > You don’t need to generate HTML documentation when creating a PPM > distribution, because it is generated automatically by the ppm client at > install. This is noted in the fact that “libdoc” and “bindoc” are set to > “undef”. I commented out the lines that generate the HTML. > > > > sub install_map (line 4830) > > > > Added some logic so that man pages are not installed unless you are running > on a Unix like operating system. > > > > Feel free to use these changes and to contact me if you have any questions > or comments. I’m glad to help in any way I can. > > > > Scott Renner > >
Re: State of Module::Build::Compatg
I think we now say "deprecated" but because there are people in your situation, I don't see actually removing it for a while -- like around the time that 5.10 is "standard" and 5.8 is rare. David On Jan 24, 2010 9:15 AM, "Marvin Humphrey" wrote: On Sat, Jan 23, 2010 at 08:26:06PM -0800, Eric Wilhelm wrote: > hard place: old client invents Makefile.PL from thin air Probably the fact that we require Perl 5.8.3 or above spares us from some of those. > If you want to encourage these users to upgrade their CPAN.pm and/or fix > their configs, deleting the Makefile.PL may be the best route. It's more the by-hand installers that have been a PITA, of which there are a couple types. There are the simpletons who have learned the "perl Makefile.PL make make test make install" incantation once upon a time, get confused and upset when their routine gets disrupted, and can't be bothered to open a README and follow simple instructions. Then there are people who learned to dislike M::B back when it was more buggy or "didn't support" their favorite EUMM feature (e.g. PREFIX), and who think it's really important to argue with me about switching to EUMM. A passthrough Makefile.PL keeps all of them out of my hair. Since Module::Build has moved to core and become more reliable these conversations end quicker, but I'd still rather not have the conversations at all. > If you're not using any M::B-only features and the "traditional" > Makefile.PL generation works for you, just do that and you won't get > complaints even in 1999. Heh. We've got a 600-line M::B subclass, which makes heavy use of ExtUtils::CBuilder and ExtUtils::ParseXS. It works like a charm, and programming with the tools built by the Module::Build team is fun. A "traditional" Makefile.PL ain't gonna cut it for us. OK, I think we'll keep the passthrough Makefile.PL for now, and thank you all for providing and maintaining the option. Once configure_requires has sufficient market penetration, we'll zap it. Cheers, Marvin Humphrey
Re: State of Module::Build::Compat
To clarify - the real issue with M::B::Compat in passthrough mode is that we have to emulate the api perfectly and that's a big source of bugs. David On Jan 23, 2010 5:46 PM, "Marvin Humphrey" wrote: Greets, I've offered passthrough Makefile.PLs on my Module::Build-based distros for the last few years, and they seem to have done what I needed them to do: stop Makefile.PL loyalists from taking up my time with complaints. However, I recently saw this on cpan-testers-discuss from David Golden: http://markmail.org/message/jzzobzsrgc6vi7tr Module::Build::Compat must die. I've got a distro that requires Perl 5.8.3 or greater that's currently got a passthrough Makefile.PL. Should I zap it? Would that help anyone out, at the cost of possibly bringing up the noise floor by some unknown amount on my support lists? Marvin Humphrey
Announcing Module::Build version 0.36
After four months of development and 15 development releases along the way, I'm pleased to announce that Module::Build 0.36 is now on CPAN. Version 0.36 will also be included in the next release of the Perl 5.11.X development series. For more, see http://search.cpan.org/dist/Module-Build-0.36/ I would like to thank everyone who contributed patches, suggestions, testing or other support to enable this release. -- David Here is a summary of major changes since 0.35: Enhancements: - Added 'Build installdeps' action to install needed dependencies via a user-configurable command line program. (Defaults to 'cpan'.) - Command line options may be set via the PERL_MB_OPT environment variable (similar to PERL_MM_OPT in ExtUtils::MakeMaker) - Generates MYMETA.yml during Build.PL (new standard protocol for communicating configuration results between toolchain components) - Reduced amount of console output under normal operation (use --verbose to see all output) - Added experimental inc/ bundling; see Module::Build::Bundling for details. New or changed properties: - Added 'share_dir' property to provide File::ShareDir support; File::ShareDir automatically added to 'requires' if 'share_dir' is set - Added 'needs_compiler' property. Defaults to true if XS or c_source exist. If true, ExtUtils::CBuilder is also added to build_requires. - 'C_support' is no longer an optional feature. Modern ExtUtils::CBuilder and ExtUtils::ParseXS added to the 'requires' list. This ensures that upgrading Module::Build will upgrade these critical modules. - Clarified that 'apache' in the license attribute indicates the Apache License 2.0 and added 'apache_1_1' for the older version of the license (RT#50614) Deprecations: - Module::Build::Compat 'passthrough' style has been deprecated. Using 'passthrough' will issue warnings on Makefile.PL generation. See Module::Build::Compat documentation for rationale. Internals: - Replaced use of YAML.pm with YAML::Tiny; Module::Build::YAML is now based on YAML::Tiny as well - A new get_metadata() method has been added as a simpler wrapper around the old, kludgy prepare_metadata() API. - Replaced guts of new_from_context(). Build.PL is now executed in a separate process before resume() is called. (This is generally only of interest to Module::Build or toolchain developers) (RT#49350) - Add support for 'package NAME VERSION' syntax added in Perl 5.11.1 Notable bug fixes: - The "test" action now dies when using the 'use_tap_harness' option and tests fail, matching the behavior under Test::Harness. (RT#49080) [initial patch from David Wheeler; revised by David Golden] - Updated PPM generation to PPM v4 (RT#49600) [Olivier Mengue] - When module_name is not supplied, no packlist was being written; fixed by guessing module_name from dist_version_from or the directory name (just like ExtUtils::Manifest does without NAME) [David Golden] - Failure to detect a compiler will now warn during Build.PL and be a fatal error when trying to compile during Build. (RT#48918) [David Golden] - Auto-detection of abstract and author fixed for mixed-case POD headers (RT#51117) [David Wheeler] - resume() was not restoring additions to @INC added in Build.PL (RT#50145) [David Golden] - When tarball paths are less than 100 characters, disables 'prefix' mode of Archive::Tar for maximum compatibility (RT#50571) [David Golden] - Merging 'requires' and 'build_requires' in Module::Build::Compat could lead to duplicate PREREQ_PM entries; now the highest version is used for PREREQ_PM. (RT#50948) [David Golden] - Module::Build::Compat will now die with an error if advanced, non-numeric prerequisites are given, as these are not supported by ExtUtils::MakeMaker in PREREQ_PM [David Golden]
Re: Please test DAGOLDEN/Module-Build-0.35_13.tar.gz
That's actually "correct" for running "perl Build.PL" since "success" means writing a Build file and metadata for CPAN/CPANPLUS to resolve prerequisites. Having Build.PL (or Makefile.PL) announce missing requirements is just a legacy behavior. It's possible they should be quiet if they detect any of the "CPAN/CPANPLUS is running" environment variables, but stock 5.8.4 wouldn't have them anyway. And the meaning of "requires" is loose. Things *may* pass if they are not satisfied, but authors don't promise anything. :-) David On Dec 7, 2009 11:55 AM, "Andy Dougherty" wrote: On Sun, 6 Dec 2009, David Golden wrote: > This is Release Candidate 3. Unless something pops up on... I tested on OpenSolaris/x86, which ships with perl-5.8.4 as the default system perl. I noted one odd thing: $ perl Build.PL Checking prerequisites... requires: ! ExtUtils::CBuilder is not installed ! ExtUtils::ParseXS is not installed build_requires: ! File::Temp (0.14) is installed, but we need version >= 0.15 ! Test::Harness (2.40) is installed, but we need version >= 3.16 ! Test::More (0.47) is installed, but we need version >= 0.49 recommends: * ExtUtils::Manifest (1.42) is installed, but we prefer to have 1.54 [ . . . ] ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions of the modules indica... $ echo $? 0 Note that although the textual output complains about missing prerequisites, the script exits with a 0 status. The "requires" things don't seem to really be required. It still "passes" all its tests, though it does skip quite a few. $ ./Build test [ . . . ] All tests successful, 6 tests and 34 subtests skipped. Files=44, Tests=1121, 78 wallclock secs (37.18 cusr + 18.89 csys = 56.07 CPU) In short, even though I'm missing several "required" prerequisites, perl Build.PL && ./Build && ./Build test && ./Build install will happily build and install, and any warnings will have scrolled hopelessly off screen. I would have expected to have to give some sort of --force flag to make it proceed anyway. -- Andy Dougherty dough...@lafayette.edu
Re: Please test DAGOLDEN/Module-Build-0.35_13.tar.gz
On Sun, Dec 6, 2009 at 11:29 PM, Craig A. Berry wrote:
> Thanks for the heads up. Below is a quick build and test, which is
> not all good news, but not entirely bad news either. This is just a
> "where we are" post and I have not even looked at the test output in
> any detail yet.
Ouch. Well, no pain, no gain. Thank you for the quick turnaround.
A couple quick reactions (other than that I probably need to find a VMS manual):
* the t/00compile.t tests look like a problem converting paths to
modules names given the particular ways paths are represented on VMS.
I thought I was doing something suitably portable, but clearly not.
* there are a lot of "Can't call method "eliminate_macros" on
unblessed reference" errors; I have no idea what's going on there
* the "no module_name" errors are again probably (again) an issue
translating between module and path names -- please see
_guess_module_name in Module::Build::Base.
Given how module/path translation seems to be at the root of some of
these, maybe we need to add "pm2path" and "path2pm" methods to
Module::Build::Base and overriding them in
Module::Build::Platform::VMS? E.g. something that would let us do
this:
File::Spec->catfile("lib",$self->pm2path("Foo::Bar")); # lib/Foo/Bar.pm
$self->path2pm(
File::Spec->abs2rel("/tmp/M-B/lib/Foo/Bar.pm","/tmp/M-B/lib") ); #
Foo::Bar
-- David
Please test DAGOLDEN/Module-Build-0.35_13.tar.gz
This is Release Candidate 3. Unless something pops up on some less-commonly tested platform, I expect this to be the final release candidate before Module::Build 0.36. Craig B. or John M. -- I'd particularly like one more test from you on VMS before I release 0.36 and write a patch for blead. Anyone else with platforms not typically covered by CPAN Testers, please test Module::Build 0.35_13 by hand and let me know if it fails. Anyone who uses custom Module::Build subclasses, please test them with this version. Thank you! -- David P.S. Here is a list of changes since the last Release Candidate: 0.35_13 - Sat Dec 5 11:26:36 EST 2009 - Protect against tempfile errors when checking ExtUtils::Installed 0.35_12 - Fri Dec 4 23:06:49 EST 2009 Bug fixes: - Protect inc/ bundling tests against broken ExtUtils::Installed 0.35_11 - Thu Dec 3 11:07:44 EST 2009 *** API CHANGE *** - The old API for prepare_metadata() has been restored to avoid breaking distributions that were overriding it (e.g. BioPerl), but the method has been marked deprecated and may be made private or may disappear in some future version of Module::Build. [David Golden] - A new get_metadata() method has been added as a simpler wrapper around the old, kludgy prepare_metadata() API. [David Golden]
Re: Plugins (was: AUTHOR_TESTING and xt?)
On Wed, Dec 2, 2009 at 6:17 PM, Eric Wilhelm wrote: > # from David Golden > # on Wednesday 02 December 2009 14:59: > >>Anyway, when that's done, I think I'll have a clearer sense of what in >>M::B is really "core" and what is "author support". That said, >>plugins are probably not on my radar in the next year. > > We can't really draw a line between "core" and "author support" -- only > between "core" and "not core" (because what was once in "core" is Sorry. I was imprecise. I was not saying "core" to mean "Perl core". Just what is *essential* for configure/build/test/install and what is extra to support authors. Much of the ACTION_* proliferation is just author support. Most of the feature bloat of M::B is either author support or configuration proliferation. More on this when I've written up the protocol more formally. > twigs and string, then you get even more mess when someone starts > copy+pasting subclass code with large swaths of M::B innards into > multiple dists. Too much of M::B is "public" interface in my opinion and it makes the whole thing brittle. >>Plus it auto-bundles itself in inc/. And Build.PL is just "use >>lib 'inc'; use Acme::Module::Build::Tiny". > > I'm looking forward to seeing that without the bundling. This would > demonstrate that configure_requires and the "Build.PL command-line API" > is maturely supported in the toolchain. Hmm. Noted. Perhaps I'll have it only bundle if 'inc' is in @INC. Or maybe not. This is Acme, after all. I was sort of trying for a kitchen sink effect in as few lines as possible. -- David
Re: Plugins (was: AUTHOR_TESTING and xt?)
On Wed, Dec 2, 2009 at 1:42 PM, Eric Wilhelm wrote: > This has triggered my semi-biyearly ponderance of plugins. I > think "tools for authors" should be doable outside of M::B. And/or > more easily customized than via subclassing, plus more easily shared > between distributions than via copy+paste. I'm working somewhat half-heartedly in my dead time in airports and what not on what I'm calling Acme::Module::Build::Tiny -- a minimalistic implementation of the "Build.PL protocol". I'm using it as a thought experiment to formalize and write up the protocol -- what CPAN/CPAN should expect to happen and be supported. It's kind of fun -- it's about 130 SLOC and is almost at the point where it's fully capable of installing itself. The .pm file is a modulino that gets copied to become Build. Plus it auto-bundles itself in inc/. And Build.PL is just "use lib 'inc'; use Acme::Module::Build::Tiny". Anyway, when that's done, I think I'll have a clearer sense of what in M::B is really "core" and what is "author support". That said, plugins are probably not on my radar in the next year. But maybe my definition of a standard protocol for Build.PL will help you. David
Re: Patch to bring Module::Build in line with current version.pm
This will go in after 0.36, as I'm currently doing (hopefully final)
release candidate testing. I'll forward your email to RT so it doesn't
get lost.
David
On Thu, Nov 26, 2009 at 9:08 AM, John Peacock
wrote:
> This patch should be applied as soon as practical, as it improves the v-string
> detection in Perl releases from 5.6.x through 5.8.0 (inclusive). It is not
> required for the 5.10.2 release (though I wouldn't cry if it were included
> anyways, just to be consistent, since 5.10.2 should ship with version.pm
> 0.78).
>
> I have an in-progress patch to deal with multiple underscores in version
> initialization, so if that lands before this gets applied, I'll provide a new
> patch.
>
> John
>
> --- lib/Module/Build/Version.pm (revision 2870)
> +++ lib/Module/Build/Version.pm (local)
> @@ -121,8 +121,7 @@
> use POSIX qw/locale_h/;
> use locale;
> use vars qw ($VERSION @ISA @REGEXS);
> -$VERSION = '0.77';
> -$VERSION = eval $VERSION;
> +$VERSION = 0.78;
>
> push @REGEXS, qr/
> ^v? # optional leading 'v'
> @@ -613,9 +612,10 @@
> sub _un_vstring {
> my $value = shift;
> # may be a v-string
> - if ( $] >= 5.006_000 && length($value) >= 3 && $value !~ /[._]/ ) {
> + if ( $] >= 5.006_000 && length($value) >= 3 && $value !~ /[._]/
> + && (ord($value) < ord('0') || ord($value) > ord('9')) ) {
> my $tvalue = sprintf("v%vd",$value);
> - if ( $tvalue =~ /^v\d+\.\d+\.\d+$/ ) {
> + if ( $tvalue =~ /^v\d+(\.\d+){2,}$/ ) {
> # must be a v-string
> $value = $tvalue;
> }
>
>
Re: AUTHOR_TESTING and xt?
On Thu, Nov 26, 2009 at 1:43 AM, Adam Kennedy wrote: > Addition to David's reply, the use of xt was suggested as a > convenience (not as a requirement) that tools may or may not choose to > use to indicate tests that run during RELEASE_TESTING. They won't > define tests that MUST be run during RELEASE_TESTING. How about this: (1) We add a "testrelease" action that sets RELEASE_TESTING and calls a list of other testing actions (2) We add a 'testxt' action that runs tests in xt/; this is common enough now that we might as well make it easy (3) We add a 'release_test_actions' parameter to set the list. This would default to qw/test testxt testpod distcheck disttest/ but could be overridden in arguments to new() I suggest this approach as some people may want pod testing, others not, some may put tests in xt, others not, some may have custom actions, others not. In the end, we set some reasonable defaults and let people change them in a way that doesn't require subclassing ACTION_testrelease just to get a different list of actions. I'll let others bikeshed the default list in #3 as I don't really care. (It gets me thinking is that 'Build release' would be easy to do similarly, either culminating in "dist" or -- if we have CPAN::Upload -- in an actual release to CPAN.) -- David
Fwd: CPAN Upload: D/DA/DAGOLDEN/Module-Build-0.35_10.tar.gz
This is Release Candidate 2. I'm re-running the regression test and will update the list with results. Please test or pray or whatever else might help. :-) Porters -- I'd greatly appreciate a test on the usual oddball operating systems that CPAN Testers won't hit. If anyone is seriously looking to help in a lazyweb sort of way, 0.35_03 changed the prepare_metadata API when we moved away from YAML to YAML::Tiny. (It used to take a YAML::Node object). It looks like Bioperl was doing some custom prepare_metadata overrides and that now breaks. If someone could offer them a nice friendly patch, that would be a huge help and gesture of solidarity since our API change breaks their distro. Thank you! -- David Changes: 0.35_10 - Tue Nov 24 22:49:19 EST 2009 Bug fixes: - bundle_inc.t is more careful about permissions and open filehandles to avoid failures/skips on Win32 [David Golden] - Fix compilation error in Module::Build::Platform::VMS (RT#51766) [David Golden] - Don't generate a MANIFEST.SKIP during distclean and add any generated MANIFEST.SKIP to cleanup list [reported by Zefram, fixed by David Golden] - Module::Build::ModuleInfo version parsing would fail if a module sets its $VERSION from another module, but the other module is not installed. We now try to detect such failures, prepend 'lib' to @INC and try again. [David Golden] - MYMETA.yml used to be generated from scratch, overriding any customizations used to create META.yml. Now, if META.yml exists, that will be used as the base for MYMETA and only prereq fields will be updated (to reflect any dynamic configuration); also, 'dynamic_config' will be set to false and 'generated_by' will be updated [David Golden]
Re: AUTHOR_TESTING and xt?
On Tue, Nov 24, 2009 at 1:23 PM, Dave Rolsky wrote: > It seems like using an xt dir and an AUTHOR_TESTING env var is the emerging > standard for managing author-only tests. > > Can we change Module::Build to include the xt dir if this env var is set? The Oslo Consensus [1] agreed to use RELEASE_TESTING, not AUTHOR_TESTING. So "no" to AUTHOR_TESTING and I'm open to the idea for RELEASE_TESTING. There was another RT wishlist item about RELEASE_TESTING as well. [2] Please add to that one or open a new RT wishlist ticket. Thanks, David [1] http://use.perl.org/~Alias/journal/36128 [2] https://rt.cpan.org/Ticket/Display.html?id=48766
Re: Custom @INC dirs lost on Module::Build->current
Already fixed in 0.35_09 thanks to a complaint by brian d foy. -- David On Tue, Nov 24, 2009 at 1:19 PM, Dave Rolsky wrote: > If I load a Module::Build subclass from a custom dir and then later, in a > separate process, call Module::Build->current, it blows up because it can't > find my subclass. > > There is already code to account for this in the generated Build script. Can > this be moved to ::Base->resume instead somehow? > > I can probably come up with a patch for this given some guidance. In > particular, where exactly should these directories be saved in _build? A new > file, or should it go in config_data? > > > -dave > > /* > http://VegGuide.org http://blog.urth.org > Your guide to all that's veg House Absolute(ly Pointless) > */ >
Re: Please test DAGOLDEN/Module-Build-0.35_09.tar.gz
On Tue, Nov 24, 2009 at 2:12 AM, Slaven Rezic wrote: > I had setup a parallel smoker to find regressions between MB 0.35 and MB > 0.35_09 on a perl 5.10.1 system. > > So far the list of differences is this one (left is new MB, right is old > MB): > > Bio-Chado-Schema-0.04300 vs. > Bio-Graphics-1.992 vs. > DateTime-Format-Builder-0.7901 vs. > Module-Build-TAPArchive-0.04 vs. > Test-DistManifest-1.005 vs. > > I only looked into Test-DistManifest and it probably it fails because it > finds the new and unexpected MYMETA.yml. I'll look into the others maybe > later this day. Thank you for taking that on. I've done a similar analysis (less dists that hit my distropref filters) and the full results are here: http://echo.dagolden.com/~xdg/mb-comparison/ I think Bio failures are due to the fact that they tend to set $VERSION = $Other::Modules::VERSION, which fails to eval. I've patched that in the repo already. They also tend to do some custom META.yml generation, which an API change broke. I'm going to examine providing backwards compatibility or else sending them a patch. M-B-TAPArchive fails because the test action now dies under TAP::Harness when there are failing tests to be consistent with the behavior under Test::Harness P5NCI fails due to the bumped prereq on ExtUtils::ParseXS. chromatic and Goro Fuji (who provided the patches that cause the failure) have been contacted and asked to sort it out I'll be chasing down the others over the next several days and will release 0.35_10 as the next release candidate (and will run regression tests again). -- David
Re: MANIFEST.SKIP mandatory?
I take patches... Otherwise, please just be patient. David On Nov 21, 2009 11:17 AM, "Zefram" wrote: David Golden wrote: >I don't want someone to "Build manifest" and add it by mistake. Maybe "./Build manifest" needs some new logic, then. Not distclean. -zefram
Re: MANIFEST.SKIP mandatory?
I don't want someone to "Build manifest" and add it by mistake. Once its added to the default in EU::Manifest, I'll make that a prereq and we're done. Progress is a bitch, eh? David On Nov 21, 2009 10:48 AM, "Zefram" wrote: David Golden wrote: >I'll sort it out. Now that we have MYMETA files we need to be sure they >don't ... The contents of the distribution is controlled by MANIFEST. There's no new reason to use SKIP files here. -zefram
Re: MANIFEST.SKIP mandatory?
I'll sort it out. Now that we have MYMETA files we need to be sure they don't get packed up in a dist. Perhaps MANIFEST.SKIP isn't the way to do it, or maybe we need to just clean up generated SKIP files. There is a patch for EU::Manifest to add MYMETA to the default skip list, but I don't think it has been released yet. David On Nov 21, 2009 8:02 AM, "Zefram" wrote: I don't use a MANIFEST.SKIP. Using Module::Build 0.35_09 (from the Perl 5.11.2 distribution), "./Build distclean" generates a MANIFEST.SKIP (1197 bytes) and MANIFEST.SKIP.bak (251 bytes), and then complains about the former not being in MANIFEST. This seems to run contrary to the "clean" part of what I asked it to do. The problem does not occur with M:B 0.35. -zefram
Re: bleadperl and bootstrapping based on Module::Build
I found the problem and it should now be fixed in blead. Unfortunately, too late for 5.11.2, but with a monthly release cycle, we'll soon be back on track. When dual-core modules moved to the cpan/ directory in the Perl source tree, the idea was in part that updating them would be a matter of just unpacking the latest tarball into that directory and deleting stuff that didn't need to be in core. Unfortunately, that doesn't work for Module::Build because Module::Build::ConfigData is dynamically generated, which I forgot when updating blead. Compounding that, the *old* ConfigData file was never moved from the lib/ directory when the powers-that-be moved M::B to the cpan/ directory, so it was still hanging around, with the old *optional features" definitions. Had it it been moved and then I blew it away, git would have warned me it was missing. So two or three small human error all compounded to create this glitch. Nevertheless, as the person doing the blead update, I take responsibility for the end result. I'm going to automate the "update blead" process so this sort of person-at-keyboard error doesn't happen again. Andreas -- thank you for reporting the problem. To everyone - my apologies for screwing this up. David
Re: bleadperl and bootstrapping based on Module::Build
On Fri, Nov 20, 2009 at 3:59 PM, Andreas J. Koenig wrote: > Something is seriously broken in the combination of > bleadperl/Module::Build, I wonder why nobody has reported this problem > besides me (or have they). Please try out what I did: No problems for me. You should only get that error if the check for the YAML_support feature gives a false positive -- that implies something really wrong in the Perl installation perhaps. $ /opt/perl/fromgit/bin/perl5.11.2 -v This is perl 5, version 11, subversion 2 (v5.11.2-20-g074f7b7*) built for x86_64-linux [snip] $ /opt/perl/fromgit/bin/perl5.11.2 Build.PL Checking prerequisites... requires: ! Config::Tiny is not installed ! Devel::Autoflush is not installed ! File::Copy::Recursive is not installed ! File::HomeDir is not installed ! File::pushd is not installed ! IO::CaptureOutput is not installed ! Probe::Perl is not installed ! Tee is not installed ! Test::Reporter is not installed ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions of the modules indicated above before proceeding with this installation Run 'Build installdeps' to install missing prerequisites. Creating new 'MYMETA.yml' with configuration results Creating new 'Build' script for 'CPAN-Reporter' version '1.1708'
Please test DAGOLDEN/Module-Build-0.35_09.tar.gz
This is "release candidate 1" (starting from 0). I think this resolves all issues that I'm aware of. I'll be migrating it into blead for 11r2 and will be re-running my regression tests. Please see changes list below: -- David 0.35_09 - Thu Nov 19 01:30:42 EST 2009 Bug fixes: - The DB package should not be included in 'provides' in META files [David Golden] - Fixed t/xs.t build failures in bleadperl for noexec temp directories [Nicholas Clark] - Adjusted order of @INC in resume() (fixes par.t, ppm.t, xs.t fails): @INC = @new_additions_to_inc, @saved_additions_to_inc, @default_inc [David Golden] - Skip bundle_inc.t tests if bundled Module::Build for test can't be tweaked (Works around test crashes on Win2) [David Golden] Other: - 'C_support' is no longer an optional feature. Modern ExtUtils::CBuilder and ExtUtils::ParseXS added to the 'requires' list. This ensures that upgrading Module::Build will upgrade this critical modules. ExtUtils::CBuilder no longer requires a compiler, so it is "safe" to require. 0.35_08 - Mon Nov 16 22:38:28 EST 2009 Bug fixes: - Multiple tests were failing due to dependency problems. Author dependencies have been largely removed from core 'requires' into optional features. Feature prereq detection and messaging have been expanded and bugs on older Perls have been removed.
Re: bundled obsolete M::B in inc/
On Wed, Nov 18, 2009 at 2:17 PM, Eric Wilhelm wrote: >>I don't know how CPANPLUS should deal with this. Maybe if >>"prereq_data" fails, you have to fall back to reading _build/prereqs. > > File a bug in EekBoek. It's not really an EekBoek issue. CPANPLUS started depending on a new M::B feature -- but based on the version of the installed perl instead of the object actually created (which is hard when running it in a separate process). Usually those are the same, but for EekBoek, they aren't. And for what it's worth, we'll have these sorts of issues again when we start switching over to MYMETA, but that at least will be easier as MYMETA either exists or it doesn't. -- David
Re: Report
On Wed, Nov 18, 2009 at 4:29 AM, Chris 'BinGOs' Williams wrote: > With the version of Module::Build installed on that smoker (0.35) the action > 'prereq_data' should be > available for the toolchain to determine which prereqs have been defined in > the Build.PL EekBoek bundles Module::Build 0.28 in inc. This is the issue that the new experimental inc/ bundling with inc::latest is intended to avoid. I don't know how CPANPLUS should deal with this. Maybe if "prereq_data" fails, you have to fall back to reading _build/prereqs. -- David
Fwd: CPAN Upload: D/DA/DAGOLDEN/Module-Build-0.35_08.tar.gz
My batting average feels pretty low these days. Sorry for all the churn. This should fix failing bundle_inc tests for Perl before 5.10.1 (with older, buggier ExtUtils::Installed). The regression test of 0.35_07 vs 0.35 has finished 0.35 tests and is about 25% of the way through 0.35_07. I expect it will be done late Tuesday or early Wednesday and we'll see how it looks. -- David -- Forwarded message -- From: PAUSE Date: Mon, Nov 16, 2009 at 10:50 PM Subject: CPAN Upload: D/DA/DAGOLDEN/Module-Build-0.35_08.tar.gz To: David Golden The uploaded file Module-Build-0.35_08.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DA/DAGOLDEN/Module-Build-0.35_08.tar.gz size: 291569 bytes md5: 7416fb7188ac81e1fe14398bd2ea4ae8 No action is required on your part Request entered by: DAGOLDEN (David Golden) Request entered on: Tue, 17 Nov 2009 03:48:58 GMT Request completed: Tue, 17 Nov 2009 03:50:09 GMT Thanks, -- paused, v1048
Fwd: CPAN Upload: D/DA/DAGOLDEN/Module-Build-0.35_07.tar.gz
Apparently, I accidentally uploaded an earlier tarball for 0.35_06 without some bug fixes. (I couldn't tell you how that happened). Please test 0.35_07 instead. Sorry about that! David
Re: Announcing DAGOLDEN/Module-Build-0.35_06.tar.gz
On Sat, Nov 14, 2009 at 12:13 PM, David E. Wheeler wrote: > > On Nov 14, 2009, at 9:04 AM, David Golden wrote: > >> This one? >> >> - Auto-detection of abstract and author fixed for mixed-case POD headers >> (RT#51117) [David Wheeler] >> >> If you want to send a patch for Changes to clarify... :-) >> >> Or just send the literal text to me in an email -- a formal patch file >> is overkill. > > Oh, that's fine. It looks like it's not in _06, though: > > http://cpansearch.perl.org/src/DAGOLDEN/Module-Build-0.35_06/Changes Odd. It should have been in there. it's in the _06 tag. I don't think I would have uploaded an old tarball, but I was doing some manual things since Eric's CPDK publish stuff was being unhappy with me. Maybe I'll have to release _07 with all the recent changes intended for _06. David
Re: Announcing DAGOLDEN/Module-Build-0.35_06.tar.gz
On Sat, Nov 14, 2009 at 11:39 AM, David E. Wheeler wrote: > ++dagolden Thanks! One note on the changes: I saw that you committed the > change in the detection of authors and the module name to ignore the case of > the =head1 tag, but I didn't see it in the Changes. Did I miss it? It's a > minor thing, but module authors probably ought to be aware of it. This one? - Auto-detection of abstract and author fixed for mixed-case POD headers (RT#51117) [David Wheeler] If you want to send a patch for Changes to clarify... :-) Or just send the literal text to me in an email -- a formal patch file is overkill. -- David
Announcing DAGOLDEN/Module-Build-0.35_06.tar.gz
Hello Module-Build and CPAN-Testers-Discuss. Module::Build 0.35_06 has arrived on CPAN. This closes all all Critical, Important and Normal bug tickets from RT that are not stalled for upstream fixes. I consider it "RC0" for 0.36 and aim to have it added to bleadperl for inclusion in the forthcoming Perl 5, Version 12 release early next year. The 0.35_XX development series has a number of new features: - Generates MYMETA.yml during Build.PL (new standard protocol for communicating configuration results between toolchain components) - Added 'needs_compiler' property. Defaults to true if XS or c_source exist. If true, ExtUtils::CBuilder is also added to build_requires. - Added 'share_dir' property to provide File::ShareDir support; set automatically if a directory called 'share' exists. File::ShareDir automatically added to 'requires' if 'share_dir' is set - Added 'Build installdeps' action to install needed dependencies via a user-configurable command line program. (Defaults to 'cpan'.) - Command line options may be set via the PERL_MB_OPT environment variable (similar to PERL_MM_OPT in ExtUtils::MakeMaker) - Reduced amount of console output under normal operation (use --verbose to see all output) - Added experimental inc/ bundling; see Module::Build::Bundling for details. See the Changes for additional details on the many bugs fixed: http://cpansearch.perl.org/src/DAGOLDEN/Module-Build-0.35_06/Changes Given the long of changes since 0.35, this RC0 needs serious testing. Module::Build authors -- please install and test with your distributions on as many versions of Perl and as many platforms as you have access to. CPAN Testers -- please consider installing it for CPAN smoke testing, but *monitor it closely* for any issues. We don't want to spam authors with FAIL reports if it's not really their fault. In the meantime, I will be kicking off my usual round of regression testing against 0.35 for the several thousand M::B using distributions on CPAN looking for any show-stoppers. Thank you for your support! David
Re: .modulebuildrc is ignored
On Tue, Nov 10, 2009 at 2:06 PM, smanzer
wrote:
> I want the module to install to a
> "~/lib/" subfolder of my home directory. I have the following .modulebuildrc
> file set up to do this:
>
> install --install_base /Users/smanzer/
>
> This installation method works if I run the scripts from the shell:
>
> Is there a way to do get these built in methods to read my .modulebuildrc
> and act accordingly?
This is a subtle issue. The .modulebuildrc is checked when the
Module::Build object is created. In your example, when you create the
Build object and then immediately dispatch to it, you never actually
set the "install" action on the command line (i.e. "Build install")
and thus that parameter in the .modulebuildrc doesn't get applied. I
suspect if you made it a wildcard, it would work.
However, if you're doing *everything* programmatically, you can just
add "install_base" directly to your object constructor:
> my $build = Module::Build->new(
>module_name => $mod_name,
>license => 'perl',
>install_base => '/Users/smanzer/'
> );
> $build->create_build_script;
> $build->dispatch('build');
> $build->dispatch('test', verbose => 1);
> $build->dispatch('install');
Hope that helps,
David
Fwd: CPAN Upload: D/DA/DAGOLDEN/Module-Build-0.35_03.tar.gz
FYI -- I've uploaded the latest dev release. This does not (yet) integrate the "inc bundling" branch, but has other significant bug fixes. It also has the new, quieter interface. -- David 0.35_03 - Wed Oct 21 21:20:59 EDT 2009 *** API CHANGE *** - The prepare_metadata() method used to take a YAML::Node object as an argument for modification. The method now takes no arguments and just returns a hash reference of metadata. [David Golden] Enhancements - Command line options may be set via the PERL_MB_OPT environment variable (similar to PERL_MM_OPT in ExtUtils::MakeMaker) Bug fixes: - Updated PPM generation to PPM v4 (RT#49600) [Olivier Mengue] - When c_source is specified, the directory scan will include additional, less-common C++ extensions (RT49298) [David Golden] - When module_name is not supplied, no packlist was being written; fixed by guessing module_name from dist_version_from or the directory name (just like ExtUtils::Manifest does without NAME) [David Golden] - Bumped IO::File prereq to fix binmode failures in PPMMaker on Perl prior to 5.8.8 [David Golden] Other: - Replaced use of YAML.pm with YAML::Tiny; Module::Build::YAML is now based on YAML::Tiny as well [David Golden] - Reduced amount of console output under normal operation (use --verbose to see all output)
Re: Integrating Module::Build and Dist::Zilla
On Fri, Oct 2, 2009 at 2:31 PM, Christopher J. Madsen wrote: > 3. Reconstruct the MB object. Tempting, but as brian d foy found, it's > not as simple as just calling Module::Build->resume. It should be easy in most cases. brian was expecting Module::Build to remember @INC at the time Build.PL created the M::B subclass object, but it doesn't. "use lib 'inc'; $mb = Module::Build->resume" should work. And if it doesn't, we'll get it fixed so it does. > 4. Run "./Build distmeta" then read META.yml. I think all the > information I need is in META.yml, although it's possible I'll discover > otherwise when I actually implement this. This has the nice side-effect > of creating a passthrough Makefile.PL (if configured in Build.PL). With a recent dev release of M::B, you can just run the Build.PL file and a MYMETA.yml file will be created that contains all that information. It's the new standard for how the toolchain can communicate distribution information between processes. That might be sufficient for your needs. -- David
Re: How do I properly use resume() and pick up inc?
On Thu, Oct 1, 2009 at 1:26 PM, brian d foy wrote: > In article > <5d4beb40909301455r6b9094d2t9e60597bdad67...@mail.gmail.com>, David > Golden wrote: > >> brian, is there any code you can share? Even some simplified examples of >> what you want in code would help us give you a solution. > > Well, the code is just the same as in my orginal question. My apologies. I was reading on a cell phone so I wasn't really following the code in the post closely. I think we're all caught up now -- this is a bug and we'll fix it soonish. David
Re: How do I properly use resume() and pick up inc?
On Tue, Sep 22, 2009 at 4:44 PM, brian d foy wrote: > * In Module::Build::Base::resume(), it adds $config_dir/lib to @INC. > Module::Build::Base::_construct() doesn't look like it does anything > with @INC either, but then it doesn't look like the original @INC is > stored in the config anyway. I'm back at a real computer and able to look at the source. You're right that M::B doesn't store things added to @INC in the config and it really should. It assumes that any subclass is "on the fly" in _build/lib rather than possibly in inc/. I noticed this when fixing a bunch of other config timing bugs relating to install directories but never got back to it. Currently, you probably need to do this: use lib 'inc'; my $mb = Module::Build->resume; It wouldn't take much effort to save @INC additions in the config somewhere and deal with them appropriately in resume(). I've created an RT ticket to track this issue: https://rt.cpan.org/Ticket/Display.html?id=50145 Thank you for noticing and reporting this. -- David
Re: How do I properly use resume() and pick up inc?
brian, is there any code you can share? Even some simplified examples of what you want in code would help us give you a solution. David On Sep 30, 2009 11:54 PM, "Eric Wilhelm" wrote: # from brian d foy # on Tuesday 29 September 2009 17:19: >> eval "require $build_class; 1" or >> die "Failed to re-load '$build_class': $@"; > >Well, ... >problem. But wait, you said you called Module::Build->resume() and got back the expected object class but without the necessary @INC. How did that happen? >Well, I'd just store the extra libs in Build i _build/config and leave >it at that without changin... That's doable, but you need that info before you resume() to deal with the require() above, right? --Eric -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --- http://scratchcomputing.com ---
Re: How do I properly use resume() and pick up inc?
I'm on vacation w/ rare access to email via cell. Quick thought: try latest dev version as some of that may have changed/been fixed recently. I'm back Oct 1 and can follow up then. D On Sep 23, 2009 10:16 PM, "brian d foy" wrote: When I use Module::Build->resume to pick up where a build left off, I'm not getting the @INC originally declared in the Build.PL. I think I'm doing something wrong. I'm working on a continuous integration and deployment system. For part of the process, we run the Build.PL, try the test targets, then have to go off to do some other work before we continue. Part of this deals with external tools, so the main program doesn't have access to the original Module::Build object. In the main program, since I know most of the set up is already done, I just want to resume. The external tool that started the whole thing may have set parameters I don't know about, so I don't want to simply re-run Build.PL. This mostly works, but I ran into a situation where I think I'm missing something I should be doing. * This problem child has a custom Module::Build subclass in the inc/ directory, and in Build I can see that just fine: unshift @INC, ( 'inc', ) * I figure that resume should pick that up: #!perl use 5.010; use Module::Build; use Data::Dumper; my $mb = Module::Build->resume; say "The subclass is ", ref $mb; say Dumper( \...@inc ); * In the output, I see the name of the right subclass, but not 'inc' in @INC. * In Module::Build::Base::resume(), it adds $config_dir/lib to @INC. Module::Build::Base::_construct() doesn't look like it does anything with @INC either, but then it doesn't look like the original @INC is stored in the config anyway.
inc bundling first draft available in svn branch
With the responses to far to design questions favoring only messing with inc/ in distdir, I've worked up a first-draft adapted from Eric's code. You can find it in the subversion branch: http://svn.perl.org/modules/Module-Build/branches/inc-bundling Here's what a Build.PL would look like using it (with a Devel::AssertOS example added): use inc::latest 'Module::Build'; use inc::latest 'Devel::AssertOS::Unix'; Module::Build->new( module_name => 'Local::Blah', license => 'perl', )->create_build_script; I've bundled up the resulting tarball if people would like to check it out and see how it works: http://echo.dagolden.com/~xdg/Local-Blah-v0.1.2.tar.gz This also includes a share/ directory, so if you run the Build.PL on a perl without File::ShareDir and with Module::Build <= 0.35, you'll see a warning that the File::ShareDir prereq isn't available. This shows that the bundled Module::Build was used as it knows to add File::ShareDir as a prereq when share/ is present. Please play around with this if you have time. After some testing, I'll merge this into the trunk. Note: Getting Devel::AssertOS* to work takes some trickery since the packlist is really under Devel::CheckOS. If there are other things you think people might be inclined to bundle, please let me know what they are so I can add them to a mapping file in M::B::Base if the packlist is under a diffferent name. This will help make it DWIM for "common" things people might bundle. (It also exposed an interesting bug for File::Spec/Cwd in that the PathTools Build.PL never defines module_name and thus doesn't create a packlist, whereas nstalling PathTools with Makefile.PL *does* create the packlist.) David
Quieting Module::Build
The latest commit to M::B silences lots of process/diagnostic messages
(unless using --verbose), making it much quieter during normal
operation.
Please check it out and send feedback on whether I've been too
aggressive or not aggressive enough. My general default was that
things getting created get logged and everything else is silent unless
there's an error.
svn commit message follows
-- David
-- Forwarded message --
From:
Date: Sat, Sep 12, 2009 at 4:41 PM
Subject: [svn:Module-Build] r13317 - in Module-Build/trunk: .
lib/Module/Build lib/Module/Build/Platform
To: svn-commit-modules-module-bu...@perl.org
Author: dagolden
Date: Sat Sep 12 13:41:02 2009
New Revision: 13317
Modified:
Module-Build/trunk/Changes
Module-Build/trunk/lib/Module/Build/Base.pm
Module-Build/trunk/lib/Module/Build/Compat.pm
Module-Build/trunk/lib/Module/Build/Platform/VMS.pm
Module-Build/trunk/lib/Module/Build/Platform/Windows.pm
Log:
Reduced amount of diagnostic output
Changed lots of log_info calls to log_verbose and rearranged some of
the prerequisites/feature output. Generally, output still happens when
files are created, but other process output is suppressed unless running
with --verbose. Errors and warnings continue to warn as before.
Modified: Module-Build/trunk/Changes
==
--- Module-Build/trunk/Changes (original)
+++ Module-Build/trunk/Changes Sat Sep 12 13:41:02 2009
@@ -15,6 +15,8 @@
Other:
- Replaced use of YAML.pm with YAML::Tiny; Module::Build::YAML is now
based on YAML::Tiny as well [David Golden]
+ - Reduced amount of console output under normal operation (use --verbose
+ to see all output)
0.35_02 - Mon Sep 7 22:37:42 EDT 2009
Modified: Module-Build/trunk/lib/Module/Build/Base.pm
==
--- Module-Build/trunk/lib/Module/Build/Base.pm (original)
+++ Module-Build/trunk/lib/Module/Build/Base.pm Sat Sep 12 13:41:02 2009
@@ -38,8 +38,19 @@
$self->check_manifest;
$self->auto_require;
- $self->check_prereq;
- $self->check_autofeatures;
+ if ( $self->check_prereq + $self->check_autofeatures != 2) {
+ $self->log_warn(<log_warn(
+ "Run 'Build installdeps' to install missing prerequisites.\n\n"
+ );
+ }
+ }
$self->dist_name;
$self->dist_version;
@@ -638,7 +649,7 @@
$self->config_file('features')
], $notes_pm);
- $self->log_info("Writing config notes to $notes_pm\n");
+ $self->log_verbose("Writing config notes to $notes_pm\n");
File::Path::mkpath(File::Basename::dirname($notes_pm));
Module::Build::Notes->write_config_data
@@ -994,7 +1005,7 @@
my $filename = File::Spec->catfile($build_dir, 'lib', split '::',
$opts{class}) . '.pm';
my $filedir = File::Basename::dirname($filename);
- $pack->log_info("Creating custom builder $filename in $filedir\n");
+ $pack->log_verbose("Creating custom builder $filename in $filedir\n");
File::Path::mkpath($filedir);
die "Can't create directory $filedir: $!" unless -d $filedir;
@@ -1157,9 +1168,7 @@
my ($self) = @_;
my $features = $self->auto_features;
- return unless %$features;
-
- $self->log_info("Checking features:\n");
+ return 1 unless %$features;
# TODO refactor into ::Util
my $longest = sub {
@@ -1175,30 +1184,40 @@
};
my $max_name_len = length($longest->(keys %$features));
+ my ($num_disabled, $log_text) = (0, "\nChecking optional features...\n");
while (my ($name, $info) = each %$features) {
- $self->log_info(" $name" . '.' x ($max_name_len - length($name) + 4));
+ my $feature_text = " $name" . '.' x ($max_name_len - length($name) + 4);
+ my $disabled;
if ( my $failures = $self->prereq_failures($info) ) {
- my $disabled = grep( /^(?:\w+_)?(?:requires|conflicts)$/,
+ $disabled = grep( /^(?:\w+_)?(?:requires|conflicts)$/,
keys %$failures ) ? 1 : 0;
- $self->log_info( $disabled ? "disabled\n" : "enabled\n" );
+ $feature_text .= $disabled ? "disabled\n" : "enabled\n";
+ $num_disabled++ if $disabled;
- my $log_text;
while (my ($type, $prereqs) = each %$failures) {
while (my ($module, $status) = each %$prereqs) {
my $required =
($type =~ /^(?:\w+_)?(?:requires|conflicts)$/) ? 1 : 0;
my $prefix = ($required) ? '-' : '*';
- $log_text .= " $prefix $status->{message}\n";
+ $feature_text .= " $prefix $status->{message}\n";
}
}
- $self->log_warn("$log_text")
Re: DWIM inc bundling design discussion (LONG)
On Sat, Sep 12, 2009 at 12:57 AM, Ron Savage wrote: > My concern is authors choosing to include a dev version of module, which > is in conflict with my policy of - as far as humanly possible - of never > installing a dev version. Simple! > > Now what happens when they do that, and the install succeeds, but when I > use their module with my non-dev - and presumably older - version, their > module does not work. E.g. is has an incompatible API. > > Or is this impossible, because I misunderstood what's going on? You've misunderstood. The bundled modules are *only* the 'configure_requires' modules. Generally, that means Module::Build and anything custom necessary to get Build.PL to run. Bundled modules are not installed. In some cases, I could see a dev version of M::B being bundled. E.g. someone really desperately wants File::ShareDir support, but we haven't released 0.36 yet. They could bundle 0.35_XX and have ShareDir support for installation. I think restricting that (a) is hard and (b) defeats a potentially important use case. David
Re: DWIM bundling dependencies
On Fri, Sep 11, 2009 at 10:42 PM, Eric Wilhelm wrote: >>Like I said, ScanDeps/TraceDeps should work most of the time. > > Devel::TraceDeps is very different from Module::ScanDeps. There's > no "most of the time" about it -- it tells you everything that got > loaded via require() or use(). Uh, huh. How about all that platform specific code that doesn't get loaded? E.g. Module::Build::Platform::VMS. The same kind of platform specific stuff happens elsewhere, like Devel::CheckOS. So it's never just a matter of seeing what loads and bundling that. There are always going to be heuristics to figure out the complete set of things to bundle. Having an 02packages file from a CPAN to map from a requested module to a distribution and then interrogating the distribution metadata is, in my opinion, the most robust way to do this. I think requiring a distribution author to have a CPAN handy is a really, really low bar. David
Re: DWIM bundling dependencies
On Fri, Sep 11, 2009 at 9:14 PM, Eric Wilhelm wrote: > I would rather that we do it without a net connection, or at least > ensure that it's the same combination of stuff that the author is > using. This is partly why I lean toward a .packlist-based scheme. You > can't really make it work at all without pure-perl modules, and there > are a few other constraints to the whole scheme. Thus, I think we > should optimize for solving the Module::Build case (90% solution.) > > In other words, at some point you reach a problem where it can't be done > or is maybe just somewhat difficult. I suggest that whatever we try to > do automagically should stop well short of that point. Like I said, ScanDeps/TraceDeps should work most of the time. Anything too complicated isn't going to bundle well, anyway. My point was that grabbing a META.yml is the only way to be sure -- and only for non arch specific dependencies, but arch-specific bundling is a nightmare anyway. -- David
Re: DWIM inc bundling design discussion (LONG)
On Fri, Sep 11, 2009 at 10:11 PM, Ron Savage wrote: > o Development releases: Can you guarantee (nothing personal :-) we won't > have another fiasco a la Data::Dumper (I think it was) a few years ago, > which seemed to have been officially released with a dev version number > (1.1_21 or some such), which, being non-numeric, caused other modules to > fail tests. I'm not sure I follow what your concern is. David
Re: DWIM inc bundling design discussion (LONG)
On Fri, Sep 11, 2009 at 8:07 PM, Ron Savage wrote: > o Obviously module authors can just not implement anything based on this > new mechanism, but for those who do... Nothing would happen by default. The idea is that if you replace "use Module::Build" in your Build.PL with "use inc::latest 'Module::Build'" then the auto-bundling will get switched on. > o A depth limit: Just how deeply will dependencies be nested? Does it > matter? To work correctly, for distribution Foo, every one of Foo's 'configure_requires' dependencies and all of the 'requires' dependencies of those must be bundled. How exactly those get nested into inc/inc_* is part of the design discussion. > o Sabotage: What if someone maliciously nests dependencies, triggering > excessive attempts to satisfy dependencies (i.e. a Denial of Service > attack)? Will some protection against this be built in? Dependency bundling would happen by the author prior to upload to CPAN. End users during install shouldn't notice a thing. Nothing prevents anything bundled from doing something malicious any more than any of the arbitrary code that runs during the install process. Note: nothing bundled in inc gets installed -- it's just there to let Build.PL finish running and identify subsequent dependencies. Those would be resolved as normal by CPAN(PLUS) or "Build installdeps" (which uses CPAN(PLUS) anyway). > o Compulsion: Is the new mechanism turned on by default simply because > it's present in the distro? Will clients (i.e. people) be able to turn > if off? Does turning it off make any sense? The idea of "inc::latest" is that you get the latest version of whatever module is loaded. If you have M::B 0.35 bundled in inc, but M::B 0.36 installed on your system, inc::latest will load M::B 0.36 from your system. But if you only have 0.34 installed, then the bundled M::B will be loaded instead. Thus you "turn it off" by having all the configure_requires dependencies installed with a version equal to or later than what is bundled. This will happen *automatically* with any recent CPAN(PLUS) client. They will make install (or otherwise make available) all configure_requires listed in META.yml before running Build.PL, in which case nothing bundled will ever get loaded. It's already part of 5.10.1. And for the rest of the Perl universe, it's a one time upgrade of CPAN.pm or CPANPLUS and then for the rest of time, configure_requires will be enabled and will take care of pre-configuration dependencies. All this inc bundling is just a stopgap for those poor souls who aren't allowed or don't know how to upgrade CPAN.pm. > o Off-line: For those of us who work on machines with no mini CPAN and > no internet access, I assume this mechanism will be self-contained, in > that everything will 'just work' without that access? Yes? As an end-user, it will "work", but of course, if you're offline and have no minicpan, how are you even downloading the distribution to install it in the first place? As an author, maybe or maybe not, depending on how we implement it. The issue is dependency resolution of configure_requires. Let's say you want to use Devel::CheckLib. That happens to depend on IO::CaptureOutput. If you've installed Devel::CheckLib, then you've got IO::CaptureOutput on your system, but there's no foolproof way to tell that Devel::CheckLib requires it and that it needs to be bundled. Module::ScanDeps is an option, but it can miss things. The safest, most robust thing to do is to get the Devel::CheckLib META.yml and get the 'requires' list from there and that needs a net connection or minicpan. We could implement various heuristics and 9/10 times it will work fine. Or, we can say that you can't "Build distdir" unless you have access to a CPAN. You can develop and test and do all that, but the actual build of a dist directory couldn't happen. Ultimately, I don't think putting that constraint on authors is too great a burden. (Side editorial -- I can't fathom why you would be developing offline without a minicpan. It's so easy to set up and only about a gig. I love being on an airplane at 30k feet and finding I want some module and being able to install it right then and there.) -- David
Re: moving all generated files to $distdir
On Fri, Sep 11, 2009 at 2:45 PM, Eric Wilhelm wrote: > I actually prefer to check-in the MANIFEST because that gives me a diff > each time it is generated, which catches bugs in MANIFEST.SKIP. > Otherwise, I guess I would have to somehow review what went into the > package and that would interrupt my release workflow. (I know, David > didn't say anything about MANIFEST, but some people have mentioned > wanting it in $distdir IIRC.) I would keep MANIFEST in $src and checked in -- but excluding files generated solely in $distdir. (This is what happens today for SIGNATURE). That way, it is a sanity check on MANIFEST.SKIP. -- David
Re: moving all generated files to $distdir
On Fri, Sep 11, 2009 at 2:03 PM, Dave Rolsky wrote: > In theory, it sounds good. I do wonder if this would require _always_ > generating the manifest a the same time though. I think the way it would work is that you wouldn't have those files in your $src/MANIFEST, but when they are written to $src/$distdir, they get added to $src/$distdir/MANIFEST That causes issue for anyone who likes it the way it is today, but if we given them an option to add to restore the old behavior, it's probably fine. I don't have strong feelings one way or the other, but I heard a lot of people clamoring for $distdir and want to see if whether we changed it, we'd find an equal number of people clamoring for the old $src behavior. David
moving all generated files to $distdir
What do people think about changing M::B's default behavior to generate all content (Makefile.PL, META.yml, README, LICENSE) in the "distdir" generated directory rather than in the top source directory? David
DWIM inc bundling design discussion (LONG)
Eric and I have had a intense off-list discussion over some design issues for inc/ bundling. I suspect a number of our differences of opinion may stem from different starting points or assumptions about the design, so I'd like to step back, be structured in my thinking about the issues and seek the input of the broader list. I think it's important that we have a strong consensus on desired *behaviors* and that we identify and address edge cases. Once we have that, I think reaching consensus on the implementation will be much easier. Context on inc::latest for those not familiar with it. inc::latest is a module that would exist as ‘inc/latest.pm’ in a distribution directory. It will be used to load the “latest” version of a module, whether bundled in inc/ or installed in the ordinary perl library path. E.g. “use inc::latest ‘Module::Build’” will load M::B from inc/ if it doesn’t exist on the user’s system or if the version in inc/ is newer than what is on the user’s system. This allows a distribution to rely on functions of newer M::B’s even if a user doesn’t have it installed and doesn’t have a CPAN(PLUS) that understands configure_requires. The way inc::latest works is by conditionally adding a specially-named directory in inc, e.g. inc/inc_Foo-Bar, to @INC, but only if inc_Foo-Bar contains a newer version of the requested module than is found in the initial @INC. It does *not* just add ‘inc’ to @INC. Clarifying some terms and assumptions for the descriptions below: * I'm going to assume a "bundle_inc" action that is responsible for the act of bundling module files into special directories in inc. (It would get called during the "distdir" action, most likely.) * When I refer to $source, I mean the top-level source directory -- e.g. the one checked out from a repo * When I refer to $distdir, I mean the Foo-Bar-1.23 directory created under $source when the "distdir" action runs * When I refer to “inc/inc_$foo” or “inc/inc_*” I mean one or all of the specially-named directories in inc/ used by inc::latest. Design issues for discussion: (1a) Should bundling modules into inc/ happen in $source or $distdir? Currently, most of the M::B created content (e.g. README, LICENSE, META.yml, and Makefile.PL) happens during the "distmeta" action and they are created in $source and added to the MANIFEST if needed. Only afterwards are files in MANIFEST copied to $distdir. The exception is SIGNATURE, which is generated within $distdir (and the MANIFEST in $dist_dir is updated to match). Bundling into inc/ in $source would be consistent with approach for other generated files. Bundling into inc/ in $distdir would better isolate bundled modules for end-users from code that is executed by authors (1b) For either choice in #1a, how should the behavior of “bundle_inc” change depending on whether $source/inc exists or is missing? If bundling inc/ happens in $source, then a missing $source/inc would result in it being created. But should an existing $source/inc be completely removed and then regenerated? Or should only the bundled files within $source/inc be removed and regenerated? If bundling inc/ happens in $distdir, then a missing $source/inc has no effect. But if $source/inc/ exists, is that an error? Should it be copied to $distdir and then bundling happens into $distdir/inc? Should bundling be done first and then $source/inc files are copied into $distdir/inc? Put differently, can a user have a $source/inc (e.g. for a custom M::B subclass) and still have bundling or not? If so, how do we make sure they play nice together? (2a) Should inc::latest work for any module at any depth in a directory bundled in inc/? (E.g., use inc::latest ‘File::Spec::Functions’) Or should inc::latest only be allowed for a “top-level” module? (e.g. use inc::latest ‘File::Spec’) If it works for any module at whatever depth, then inc::latest must search *all* directory bundles in inc/ for one containing the requested module. If the module is found in inc/inc_* and has a higher $VERSION than in @INC, the bundled inc/inc_$foo in unshifted to @INC and the module is loaded. (Note: when this happens means *all* modules in inc/inc_$foo will subsequently take precendence over system-installed modules. E.g. File::Spec::Functions loads File::Spec but as long as they are in the same bundle, the correct ‘latest’ version will be loaded.) If it works only for a top-level module, then inc::latest checks if inc/inc_$foo exists and whether the module there has a higher $VERSION number than in @INC. If so, inc/inc_$foo is unshifted to @INC and the module is loaded. (Again, all modules in inc/inc_$foo will now take precedence, not only the one initially loaded.) This means that an author may have load a top level module with inc::latest just to set up @INC to then use a module that is deeper in the tree. E.g. “use inc::latest ‘File::Spec’; use File::Spec::Functions” (2b) Should modules to bundle be based on configure_requir
