headers
Gabor Szabo | 3 Jan 2013 12:04
Favicon

How to create META.json using Module::Build and how to link to the VCS?

Hi,

recently I wrote an article how people could include a link to their
version control system in the META.yml file.
http://perl5maven.com/how-to-add-link-to-version-control-system-of-a-cpan-distributions

After getting a few comments I found out that beside the link to the
repository one could also include the type of
the repository (git/svn/etc...), but as far as I can see only
META.json holds that information.
At least in the distributions I checked only META.json had this.
All these distributions were generated using Dist::Zilla.

So I wonder how can ask Module::Build to generate META.json as well,
and how can I tell it
to include the other fields of the repository as well?

regards
   Gabor
Permalink | Reply | 5 comments |
headers
Lyle | 1 Jan 2013 21:25

Fwd: [rt.cpan.org #82306] Not building for Perl 5.16 on Windows

I submitted a bug to rjbs about one of his modules not building on 
Windows. He's kicked back that it's actually a Module::Build error. 
Looking at the build log, it appears he's correct:
http://ppm4.activestate.com/MSWin32-x86/5.16/1600/R/RJ/RJBS/CGI-Application-Server-0.062.d/log-20120819T121907.txt
Then I would presume that this is affecting a lot of modules?

Lyle

-------- Original Message --------
Subject: 	[rt.cpan.org #82306] Not building for Perl 5.16 on Windows
Date: 	Tue, 1 Jan 2013 15:13:41 -0500
From: 	Ricardo Signes via RT <bug-CGI-Application-Server <at> rt.cpan.org>
Reply-To: 	bug-CGI-Application-Server <at> rt.cpan.org
To: 	COSMICNET <at> cpan.org

<URL: https://rt.cpan.org/Ticket/Display.html?id=82306 >

This bug is a failure of Module::Build to compile.

It is related to CGI::Application::Server only in that its Build.PL loads Module::Build.

--

-- 
rjbs
Permalink | Reply | 2 comments |
headers
Jan Dubois | 28 Dec 2012 02:44
Picon
Gravatar

Fwd: How To Build A Perl Package Database

---------- Forwarded message ----------
From: Jan Dubois <jand <at> activestate.com>
Date: Thu, Dec 27, 2012 at 5:40 PM
Subject: Re: How To Build A Perl Package Database
To: Leon Timmermans <fawaka <at> gmail.com>

On Thu, Dec 20, 2012 at 2:42 AM, Leon Timmermans <fawaka <at> gmail.com> wrote:

> On Mon, Dec 17, 2012 at 9:36 AM, Tim Bunce <Tim.Bunce <at> pobox.com> wrote:
> > A separate install database for each install location seems like the only
> > workable approach.
>
> One minor complication of that is the strictest sense an "install
> location" isn't all that well defined. Or perhaps I should say every
> dist has 8 install locations with unspecified relationship on the
> filesystem (lib, arch, bin, script, libdoc, bindoc, libhtml, binhtml).
> In practice you may want to use lib *and* arch (they are never used
> simultaneously, but stuff in lib may be shared over different perl
> installations, contrary to arch which should be for one specific
> install).
>

I wonder if it isn't time to deprecate all the complex install combinations
that may have made sense when hard disks was rather limited.

In ActivePerl we enforce a pretty simplified install layout to be able to
create an intuitive package manager:

   - no sharing of directories between different versions
   - every install area has its own bin, etc, lib, and html subdirectories
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael G Schwern | 15 Dec 2012 23:59
Picon
Favicon
Gravatar

How To Build A Perl Package Database

We have a lot of serious problems because we lack a database of installed
distributions, releases and files.  There are serious problems with
implementing one given A) the limitations of the standard Perl install and B)
wedging it into existing systems.  But I think I have a solution.  Its similar
to how meta data was slipped into the ecosystem without requiring authors to
rewrite their releases or install a bunch of extra modules.  It just happens
as part of the normal CPAN module upgrade process.

I've been thinking that a minimal package database could be created by putting
some hooks into ExtUtils::Install::install(), which every Perl build system
ultimately uses, to record what gets installed.  That way when
ExtUtils::Install is upgraded, the user gets a build database without
upgrading everything else.

This would be a fairly straight forward process at install time...

1) Copy everything to a temp directory
2) Record everything in that temp directory
3) Copy everything from temp into the real location

You could probably optimize this by skipping the copy to temp and just have
install() record stuff as it goes by, but this is the dumb, simple, robust way
to do it.

Storage is a problem.  The only reliable "database" Perl ships with is DBM, an
on disk hash, so we can't get too fancy.  It might take several DBM files, but
this is enough to record information and do simple queries.  What are those
queries?

* What version of the database is this?
(Continue reading)

Permalink | Reply | 24 comments |
headers
Alberto Simões | 15 Dec 2012 18:20
Picon
Favicon
Gravatar

Uninstalling obsolete module files

Hello

It would be cool if a module could obsolete other module.

For instance, I noticed that Net::DNS no longer installs 
Net::DNS::Domain. This means the Domain.pm file will be hanging in the 
system until a full reinstall of the perl module tree is done.

Just like one can specify a list of PM files in the distribution, it 
would be cool if we could specify a list of modules that get obsolete 
with this installation, something like:

     obsoletes_modules => [ 'Net::DNS::Domain' ],

One could maintain this information for a few releases, and the install 
action would remove the Domain.pm file if it finds it.

Thoughts on this?

Cheers,
ambs
Permalink | Reply | 5 comments |
headers
John M. Gamble | 17 Nov 2012 01:53
Picon
Favicon

The get_options Argument to new()

I managed to get around this using the args() method, so this isn't a
critical problem. But I was wondering if I used the get_options argument
incorrectly.

What I had was:

my $test_all = 0;

my $build = Module::Build->new(
my $build = $class->new(

	license => 'perl',

	get_options => {
		Testall => {store => \$test_all},
	},
#... etc.
);

$build->create_build_script;

It creates the Build file correctly, but when I try the command

Build test --Testall

I get the error message

Modification of a read-only value attempted at
C:/Perl64/lib/Getopt/Long.pm line 561.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John M. Gamble | 7 Nov 2012 02:23
Picon
Favicon

Passing Options to Test Files

I have tests in a module that take a long time to run. Strictly speaking,
the CPAN testers don't need to run all of them, so it makes sense to have
them automatically skipped, letting me run them manually when I want.

Reading the Module::Build::API document, I see that I can create my own
option (e.g., --Testall) using the get_options parameter. But it looks
like I can only pass information to the test files via tap_harness_args
to TAP::Harness.  Currently, all but two of my test files use Test::Simple,
with the remaining files using Test::More.

Do I have to re-write my test files to use TAP::Harness?

Thanks,
     -john
Permalink | Reply | 1 comment |
headers
Boyd Duffee | 11 Oct 2012 18:49
Picon
Favicon

subclassing Action_install

Hi again,

Trying to learn more about custom install.  I ran across the Modifying an
Action section in Module::Build::Cookbook and tried to shoehorn that bit of
code into my script.  When I run
	perl Build.PL
I get
	Can't use string as a HASH ref while "strict refs" in use
when I call the create_build_script() method.  I've attached the Build.PL
file.  What am I doing wrong?

many thanks,
Boyd

I'm using M::B v0.4 / Fedora 13 / perl v5.10.1 x86_64-linux-thread-multi

This is me stepping through the build process with the debugger

Module::Build::Base::write_config(/usr/share/perl5/Module/Build/Base.pm:1318):
1318:	  File::Path::mkpath($self->{properties}{config_dir});
  DB<1>
Can't use string ("Module::Build::Custom") as a HASH ref while "strict refs"
in use at /usr/share/perl5/Module/Build/Base.pm line 1318.
 at /usr/share/perl5/Module/Build/Base.pm line 1318
	Module::Build::Base::write_config('Module::Build::Custom') called at
/usr/share/perl5/Module/Build/Base.pm line 1956
	Module::Build::Base::create_build_script('Module::Build::Custom') called at
Build.PL line 56
Module::Build::Base::CODE(0x17d23d0)(/usr/share/perl5/Module/Build/Base.pm:1258):
1258:	    for my $f ( map glob($_),  <at> { $unlink_list_for_pid{$$} || [] } ) {
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Mertens | 11 Oct 2012 13:21
Picon

Fwd: Re: added check for shell in installed script

Forgot to reply to all.
---------- Forwarded message ----------
From: "David Mertens" <dcmertens.perl <at> gmail.com>
Date: Oct 11, 2012 6:20 AM
Subject: Re: added check for shell in installed script
To: "Boyd Duffee" <b.duffee <at> keele.ac.uk>

I thought this was just standard procedure for preventing silly users from
shooting their foot off by accidentally running your script with a shell,
instead of with Perl. Does EU::MM not do this? Module::Build does a few
things like this with scripts. For example, on Windows it creates .bat
files with the script name so that users can "just run" the script on their
OS.

David
On Oct 11, 2012 2:37 AM, "Boyd Duffee" <b.duffee <at> keele.ac.uk> wrote:

> Hi there,
>
> I found the following line added to a script that I created with
> Module::Build 0.4 and used Module::Build 0.38 to install
>
> eval 'exec /usr/bin/perl -wT -S $0 ${1+"$ <at> "}'
>     if 0; # not running under some shell
>
> I wasn't expecting that and I'm not sure that I want it.  It doesn't
> mention
> this behaviour in the docs.  Can someone explain why?  This is my Build.PL
> script.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Boyd Duffee | 10 Oct 2012 18:42
Picon
Favicon

added check for shell in installed script

Hi there,

I found the following line added to a script that I created with
Module::Build 0.4 and used Module::Build 0.38 to install

eval 'exec /usr/bin/perl -wT -S $0 ${1+"$ <at> "}'
    if 0; # not running under some shell

I wasn't expecting that and I'm not sure that I want it.  It doesn't mention
this behaviour in the docs.  This is my Build.PL script.

my $builder = Module::Build->new(
    module_name         => 'Keele::Utilities::Database',
    license             => 'perl',
    dist_author         => q{Boyd Duffee <b.duffee at isc.keele.ac.uk>},
    dist_version_from   => 'lib/Keele/Utilities/Database.pm',
    requires    => {
        'DBI'   => '1.52',
        'Keele::Utilities'  => '0.03',
        'Date::Manip'   => 0,
    },
    build_requires => {
        'Test::More' => 0,
    },
    configure_requires => {
        'Module::Build' => 0.38,
    },
    add_to_cleanup      => [ 'Keele-Utilities-Database-*' ],
    create_makefile_pl => 'traditional',
    script_files        => {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boyd Duffee | 11 Oct 2012 09:37
Picon
Favicon

added check for shell in installed script

Hi there,

I found the following line added to a script that I created with
Module::Build 0.4 and used Module::Build 0.38 to install

eval 'exec /usr/bin/perl -wT -S $0 ${1+"$ <at> "}'
    if 0; # not running under some shell

I wasn't expecting that and I'm not sure that I want it.  It doesn't mention
this behaviour in the docs.  Can someone explain why?  This is my Build.PL
script.

my $builder = Module::Build->new(
    module_name         => 'Keele::Utilities::Database',
    license             => 'perl',
    dist_author         => q{Boyd Duffee <b.duffee at isc.keele.ac.uk>},
    dist_version_from   => 'lib/Keele/Utilities/Database.pm',
    requires    => {
        'DBI'   => '1.52',
        'Keele::Utilities'  => '0.03',
        'Date::Manip'   => 0,
    },
    build_requires => {
        'Test::More' => 0,
    },
    configure_requires => {
        'Module::Build' => 0.38,
    },
    add_to_cleanup      => [ 'Keele-Utilities-Database-*' ],
    create_makefile_pl => 'traditional',
(Continue reading)

Permalink | Reply | 0 comments |

Gmane