module-build-general — General discussion about Module::Build project

[Module-build-general] Module::Build and Module::Install

[Ed A. <ed...@me...>]

What is the connection between Module::Build and Module::Install?  
The documentation
<http://search.cpan.org/author/KWILLIAMS/Module-Build-0.20_01/lib/Module/Build.pm>
says:

>If you want the installation process to look around in @INC for other
>versions of the stuff you're installing and try to delete it, you can
>use the uninst parameter, which tells Module::Install to do so:

but doesn't mention that module anywhere else.

-- 
Ed Avis <ed...@me...>

Re: [Module-build-general] [idea] readme_from => $file

[Michael G S. <sc...@po...>]

On Fri, Sep 12, 2003 at 02:48:35PM -0500, Ken Williams wrote:
> You're reading my mind!  Earlier this week I committed a patch adding a 
> "create_readme" parameter, which uses the file in dist_version_from to 
> generate a README using pod2html.  Will you need more flexibility than 
> that?

pod2html?  By all that is 7bit ASCII I hope you meant Pod::Text.


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
Death?  Its like being on holiday with a group of Germans.

Re: [Module-build-general] [idea] readme_from => $file

[Steve P. <sp...@qu...>]

On Friday, September 12, 2003, at 08:48  pm, Ken Williams wrote:

>
> On Friday, September 12, 2003, at 10:07  AM, Steve Purkis wrote:
>
>> Hi all,
>>
>> I'm one of those people who uses pod2text to generate my README files 
>> - problem is I keep forgetting to update the README before making a 
>> dist, which is a bit annoying when you go to all the effort of 
>> updating the pod!
>>
>> So I thought perhaps this would be a good thing for Module::Build to 
>> take on -- entirely optional, of course.  Perhaps another parameter 
>> to new():
>>
>> 	readme_from => $file
>>
>> If this param existed, your README file would be generated everytime 
>> you did:
>>
>> 	./Build dist
>> 	./Build readme
>>
>> Do other people think that's a good idea?
>
> You're reading my mind!  Earlier this week I committed a patch adding 
> a "create_readme" parameter, which uses the file in dist_version_from 
> to generate a README using pod2html.  Will you need more flexibility 
> than that?

Nope, that's perfect ;).  Ta for the good news - I'll update my copy 
from cvs.

-Steve

Re: [Module-build-general] [idea] readme_from => $file

[Ken W. <ke...@ma...>]

On Friday, September 12, 2003, at 10:07  AM, Steve Purkis wrote:

> Hi all,
>
> I'm one of those people who uses pod2text to generate my README files 
> - problem is I keep forgetting to update the README before making a 
> dist, which is a bit annoying when you go to all the effort of 
> updating the pod!
>
> So I thought perhaps this would be a good thing for Module::Build to 
> take on -- entirely optional, of course.  Perhaps another parameter to 
> new():
>
> 	readme_from => $file
>
> If this param existed, your README file would be generated everytime 
> you did:
>
> 	./Build dist
> 	./Build readme
>
> Do other people think that's a good idea?

You're reading my mind!  Earlier this week I committed a patch adding a 
"create_readme" parameter, which uses the file in dist_version_from to 
generate a README using pod2html.  Will you need more flexibility than 
that?

  -Ken

Re: [Module-build-general] no prereq detection with Module::Build->dispatch

[Ken W. <ke...@ma...>]

On Friday, September 12, 2003, at 09:35  AM, Jos I. Boumans wrote:
>
> * Is there a nicer way to get the prereqs out of the $m object, rather 
> than poking into it?

Try the prereq_failures() method - or do you need more than just the 
unfulfilled prereqs?

  -Ken

Re: [Module-build-general] no prereq detection with Module::Build->dispatch

[Ken W. <ke...@ma...>]

Hey Jos,

It's not a bug, but you can't actually do what you want to do yet, at 
least not very easily.  Of course, what you want to do would be useful. 
  I'm working on a couple small patches to M::B that should get it to 
work in an even simpler way.  You'll essentially end up doing something 
like this:

  chdir("whatever/mb_test/");
  my $build = Module::Build->new_from_context();
  $build->dispatch('build');
  $build->dispatch('test');
  $build->dispatch('install');

Still not sure the best name for the new_from_context() method.  Its 
purpose is to look at the META.yml file, then run the Build.PL script 
if necessary (non-interactive builds won't require it), and return a 
M::B object the user can act on.

  -Ken


On Friday, September 12, 2003, at 09:35  AM, Jos I. Boumans wrote:

> Hi, i'm trying to add proper module::build support for CPANPLUS, but 
> i'm getting quite confused by the docs. On top of that, i think i've 
> run into a bug:
>
> [kane@coke ~...Perl/mb_test]$ cat mb.pl
> use Module::Build;
> use Data::Dumper;
> chdir 'Class-DBI-ToSax-0.09';
> my $m = new Module::Build (module_name => 'Class::DBI::ToSax' );
> $m->dispatch('build');
> print Dumper $m->{properties};
>
> [kane@coke ~...Perl/mb_test]$ perlc mb.pl
> Checking whether your kit is complete...
> Looks good
> $VAR1 = {
>           'script_files' => [],
>           'build_script' => 'Build',
>           'perl' => '/opt/perl/bin/perl',
>           'build_requires' => {},
>           'dist_name' => 'Class-DBI-ToSax',
>           'base_dir' => 
> '/Users/kane/Documents/Perl/mb_test/Class-DBI-ToSax-0.09',
>           'module_name' => 'Class::DBI::ToSax',
>           'conflicts' => {},
>           'requires' => {},
>           'recommends' => {},
>           'config_dir' => '_build',
>           'dist_version_from' => 'lib/Class/DBI/ToSax.pm',
>           'dist_version' => '0.09'
>         };
>
> as you can see, it's not detecting any prerequisites...
> however, seeing the Build.PL:
>
> Module::Build->new(
>     module_name => 'Class::DBI::ToSax',    license     => 'perl',
>     requires    => {
>         # Bug in 5.6.0 isa()...
>         'perl'       => '5.6.1',
>         'Test::More' => 0,
>         # Both of these are required by Class::DBI, so shouldn't be too
>         # onerous...
>         'Class::Accessor'          => 0,
>         'Class::Data::Inheritable' => 0,
>         # DCONWAY rocks.
>         'NEXT' => 0,
>         # Most people will want this and it's good for testing.        
> 'XML::SAX::Writer' => 0,
>     },
> )->create_build_script;
>
> i've tried this for a few more modules, but none of them come up with 
> the prereqs.
>
> A few more questions though.
> * With a normal installation, one would do:
> 	perl Build.PL
> 	perl Build
> 	perl Build test
> 	perl Build install
>
> this translates to the following dispatch table:
> 	build
> 	test
> 	install
>
> what action for 'dispatch' is equivalent to 'perl Build.PL' ?
> is that the new call? i don't see that documented....
>
> * Is there a nicer way to get the prereqs out of the $m object, rather 
> than poking into it?
>
> 	
> --
>
> Jos Boumans
>
> 	"You know you are never more indignant in life than when you're
> 	shopping at a store you feel is beneath you and one of the other
> 	customers mistakes you for one of the employees of that store."
> 		- Dennis Miller
>
> 	CPANPLUS	http://cpanplus.sf.net
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

[Module-build-general] [idea] readme_from => $file

[Steve P. <sp...@qu...>]

Hi all,

I'm one of those people who uses pod2text to generate my README files - 
problem is I keep forgetting to update the README before making a dist, 
which is a bit annoying when you go to all the effort of updating the 
pod!

So I thought perhaps this would be a good thing for Module::Build to 
take on -- entirely optional, of course.  Perhaps another parameter to 
new():

	readme_from => $file

If this param existed, your README file would be generated everytime 
you did:

	./Build dist
	./Build readme

Do other people think that's a good idea?
-Steve

[Module-build-general] no prereq detection with Module::Build->dispatch

[Jos I. B. <ka...@xs...>]

Hi, i'm trying to add proper module::build support for CPANPLUS, but 
i'm getting quite confused by the docs. On top of that, i think i've 
run into a bug:

[kane@coke ~...Perl/mb_test]$ cat mb.pl
use Module::Build;
use Data::Dumper;
chdir 'Class-DBI-ToSax-0.09';
my $m = new Module::Build (module_name => 'Class::DBI::ToSax' );
$m->dispatch('build');
print Dumper $m->{properties};

[kane@coke ~...Perl/mb_test]$ perlc mb.pl
Checking whether your kit is complete...
Looks good
$VAR1 = {
           'script_files' => [],
           'build_script' => 'Build',
           'perl' => '/opt/perl/bin/perl',
           'build_requires' => {},
           'dist_name' => 'Class-DBI-ToSax',
           'base_dir' => 
'/Users/kane/Documents/Perl/mb_test/Class-DBI-ToSax-0.09',
           'module_name' => 'Class::DBI::ToSax',
           'conflicts' => {},
           'requires' => {},
           'recommends' => {},
           'config_dir' => '_build',
           'dist_version_from' => 'lib/Class/DBI/ToSax.pm',
           'dist_version' => '0.09'
         };

as you can see, it's not detecting any prerequisites...
however, seeing the Build.PL:

Module::Build->new(
     module_name => 'Class::DBI::ToSax',    license     => 'perl',
     requires    => {
         # Bug in 5.6.0 isa()...
         'perl'       => '5.6.1',
         'Test::More' => 0,
         # Both of these are required by Class::DBI, so shouldn't be too
         # onerous...
         'Class::Accessor'          => 0,
         'Class::Data::Inheritable' => 0,
         # DCONWAY rocks.
         'NEXT' => 0,
         # Most people will want this and it's good for testing.        
'XML::SAX::Writer' => 0,
     },
)->create_build_script;

i've tried this for a few more modules, but none of them come up with 
the prereqs.

A few more questions though.
* With a normal installation, one would do:
	perl Build.PL
	perl Build
	perl Build test
	perl Build install

this translates to the following dispatch table:
	build
	test
	install

what action for 'dispatch' is equivalent to 'perl Build.PL' ?
is that the new call? i don't see that documented....

* Is there a nicer way to get the prereqs out of the $m object, rather 
than poking into it?

	
--

Jos Boumans

	"You know you are never more indignant in life than when you're
	shopping at a store you feel is beneath you and one of the other
	customers mistakes you for one of the employees of that store."
		- Dennis Miller

	CPANPLUS	http://cpanplus.sf.net

Re: [Module-build-general] document do_system?

[Ken W. <ke...@ma...>]

On Thursday, September 11, 2003, at 12:24  PM, Dave Rolsky wrote:

> Here's some docs:
>
> =item do_system($cmd, @args)
>
> Given a command and an array of optional arguments, this method will 
> print
> the command to C<STDOUT>, and then execute it using Perl's C<system()>
> built-in.  It returns true or false to indicate success or failure, 
> which
> is the opposite of how Perl's built-in command works.
>


Tweaked and added, thanks.

  -Ken

Re: [Module-build-general] Warning on shebang/extending M::B

[Ken Y. C. <kc...@lo...>]

On Wed, 10 Sep 2003, Dave Rolsky wrote:

> Date: Wed, 10 Sep 2003 16:50:48 -0500 (CDT)
> From: Dave Rolsky <au...@ur...>
> To: mod...@li...
> Subject: Re: [Module-build-general] Warning on shebang/extending M::B
>
> On Wed, 10 Sep 2003, Ken Y. Clark wrote:
>
> > practices when it comes to what I want to do.  Specifically, I want to
> > copy HTML templates, an HTML stylesheet, and a configuration file to
> > the directories the user has set (or the defaults I have in my
> > script).  Then I just want to let M::B do it's thing.  Something like:
> >
> >     sub ACTION_install {
> >         my $self = shift;
> >         copy_files('templates', $template_dir);
> >         copy_files('conf/cmap.conf', $conf_dir);
> >         copy_files('conf/cmap.css', $ss_dir);
> >         $self->SUPER::ACTION_install;
> >     }
> >
> > Does that look reasonable?  Any suggestions on the best way to write
> > the "copy_files" part?
>
> Check out the 'copy_if_modified' method.  That's what it is there for.

Ah, thanks for that pointer.  I glossed over that method.

Any chance to get "copy_if_modified" to also take a "from_dir"
argument and have it glob everything in there (perhaps recursively
grabbing sub-dirs)?

> But use File::Spec in to get 'conf/cmap.conf' for portability!.

Another great tip.  Thanks!

ky

[Module-build-general] document do_system?

[Dave R. <au...@ur...>]

Here's some docs:

=item do_system($cmd, @args)

Given a command and an array of optional arguments, this method will print
the command to C<STDOUT>, and then execute it using Perl's C<system()>
built-in.  It returns true or false to indicate success or failure, which
is the opposite of how Perl's built-in command works.



-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] Warning on shebang/extending M::B

[Dave R. <au...@ur...>]

On Wed, 10 Sep 2003, Ken Y. Clark wrote:

> practices when it comes to what I want to do.  Specifically, I want to
> copy HTML templates, an HTML stylesheet, and a configuration file to
> the directories the user has set (or the defaults I have in my
> script).  Then I just want to let M::B do it's thing.  Something like:
>
>     sub ACTION_install {
>         my $self = shift;
>         copy_files('templates', $template_dir);
>         copy_files('conf/cmap.conf', $conf_dir);
>         copy_files('conf/cmap.css', $ss_dir);
>         $self->SUPER::ACTION_install;
>     }
>
> Does that look reasonable?  Any suggestions on the best way to write
> the "copy_files" part?

Check out the 'copy_if_modified' method.  That's what it is there for.

But use File::Spec in to get 'conf/cmap.conf' for portability!.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] Warning on shebang/extending M::B

[Dave R. <au...@ur...>]

On Wed, 10 Sep 2003, Ken Y. Clark wrote:

> 2.  The main reason I want to move away from MakeMaker is because I have
>     a number of files (HTML templates, configuration files, stylesheet)
>     that I want to install into directories that the user defines as
>     arguments to Build.PL.  In MM, I'd create extra targets for the
>     "make install," but with Module::Build the docs say I ought to be
>     able to just add some code to "ACTION_install" to get this to
>     happen, but I'm not having any luck.  Even something simple like
>     this doesn't work:
>
>     my $builder           =  Module::Build->subclass(
>         class             => 'My::Builder',
>         code              => q[
>             sub ACTION_install {
>                 my $self = shift;
>                 print "Yo!\n";
>             }
>         ]
>     )->new(
>         module_name       => 'Bio::GMOD::CMap',
>         dist_author       => 'Ken Y. Clark <kc...@cs...>',
>         dist_name         => 'cmap',
>         dist_version_from => 'lib/Bio/GMOD/CMap.pm',
>         license           => 'gpl',
>     );
>     $builder->create_build_script;
>
>     When I run "./Build fakeinstall" (because I don't want to actually
>     install on this machine), I don't see "Yo" but I do see lots of
>     "Installing..." statements.  I've scoured the docs, looked at the
>     Cookbook, read the perl.com article, and searched the list archives,
>     but I don't really see how I can add some actions like this.  I'd
>     really appreciate a point to the right docs if they exist, or some
>     help in making them if they don't.

fakeinstall is a separate action, implemented by a separate method.  This
should probably be stated explicitly in the docs, because your expectation
seems reasonable.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

[Module-build-general] Warning on shebang/extending M::B

[Ken Y. C. <kc...@lo...>]

I've been trying to convert a distribution of mine over to use
Module::Build, and I've got a couple of questions

1.  This is mostly just annoying and isn't really stopping anything,
    but, after I run "perl Build.PL," I get this warning:

    * WARNING: Configuration was initially created with '/usr/bin/perl',
      but we are now using '/usr/local/bin/perl'.

    Both perl's are the same, so it's not a version problem, but see:

    $ which perl
    /usr/bin/perl

    $ perl -MConfig -e 'print "$Config::Config{startperl}\n"'
    #!/usr/local/bin/perl

    And the latter is what Module::Build::Base::print_build_script uses.
    Is there a way to fix this so that it uses whatever is the path for
    the binary used to execute "Build.PL" instead?

2.  The main reason I want to move away from MakeMaker is because I have
    a number of files (HTML templates, configuration files, stylesheet)
    that I want to install into directories that the user defines as
    arguments to Build.PL.  In MM, I'd create extra targets for the
    "make install," but with Module::Build the docs say I ought to be
    able to just add some code to "ACTION_install" to get this to
    happen, but I'm not having any luck.  Even something simple like
    this doesn't work:

    my $builder           =  Module::Build->subclass(
        class             => 'My::Builder',
        code              => q[
            sub ACTION_install {
                my $self = shift;
                print "Yo!\n";
            }
        ]
    )->new(
        module_name       => 'Bio::GMOD::CMap',
        dist_author       => 'Ken Y. Clark <kc...@cs...>',
        dist_name         => 'cmap',
        dist_version_from => 'lib/Bio/GMOD/CMap.pm',
        license           => 'gpl',
    );
    $builder->create_build_script;

    When I run "./Build fakeinstall" (because I don't want to actually
    install on this machine), I don't see "Yo" but I do see lots of
    "Installing..." statements.  I've scoured the docs, looked at the
    Cookbook, read the perl.com article, and searched the list archives,
    but I don't really see how I can add some actions like this.  I'd
    really appreciate a point to the right docs if they exist, or some
    help in making them if they don't.

Also, FWIW, some of the pmtools complain about
Module::Build::Cookbook, e.g.:

    $ pmpath Module::Build::Cookbook
    /usr/local/bin/pmpath: Module/Build/Cookbook.pm did not return a true value

ky

[Module-build-general] build_recommends argument for new()?

[Dennis S. <de...@su...>]

Would it be possible to include a build_recommends argument for the new()
method?

I have a module which optionally uses the module Struct::Compare in build
tests, if that module is found.  This module really shouldn't be
designated as "build_requires", since it is not necessary for the build.

Re: [Module-build-general] create_makefile_pl option

[Ken W. <ke...@ma...>]

On Tuesday, September 9, 2003, at 03:46  PM, Dave Rolsky wrote:

> If this is set, then the distdir action will make a Makefile.PL, but it
> does it in the current directory, not the distdir.  That seems wrong.

The idea is that it gets created in the current directory, then copied 
to the distdir by manicopy().


> Also, could it check to see if Makefile.PL was in the MANIFEST when it
> does this and give a warning if its not?

Yeah, true.

  -Ken

[Module-build-general] create_makefile_pl option

[Dave R. <au...@ur...>]

If this is set, then the distdir action will make a Makefile.PL, but it
does it in the current directory, not the distdir.  That seems wrong.

Also, could it check to see if Makefile.PL was in the MANIFEST when it
does this and give a warning if its not?

-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] [PATCH] signing fixes

[Ken W. <ke...@ma...>]

On Tuesday, September 9, 2003, at 11:00  AM, Dave Rolsky wrote:
>
> But the current code will now end up adding it twice if for some reason
> the user _does_ add it to their MANIFEST.  At the very least, you 
> should
> document this and tell users not to ever add it.

Agreed, I'll do that.

  -Ken

Re: [Module-build-general] [PATCH] signing fixes

[Dave R. <au...@ur...>]

On Tue, 9 Sep 2003, Ken Williams wrote:

> I think the SIGNATURE file needs to be a special case.  The user can't
> add it to the MANIFEST him/herself, because then
>
>   * if SIGNATURE exists in the base directory, it won't be valid - and
> the only reason to create it would be to satisfy the hunger of
> manicopy().
>
>   * if SIGNATURE doesn't exist in the base directory, then manicopy()
> will fail.
>
> And since it needs to be added to the MANIFEST somehow, I think M::B
> has to do it.  This combination also means that the 'manifest' action
> will continue to work correctly too.

But the current code will now end up adding it twice if for some reason
the user _does_ add it to their MANIFEST.  At the very least, you should
document this and tell users not to ever add it.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

[Module-build-general] new beta uploaded

[Ken W. <ke...@ma...>]

Hey,

I uploaded a new beta of Module::Build, 0.20_01, to CPAN and 
Sourceforge.  Changes are:

  - When signing distributions with Module::Signature, we now
    automatically add the SIGNATURE file to the MANIFEST, avoiding an
    unpleasant chicken/egg problem for the module author.
    [unpleasantness spotted by sungo]

  - In Module::Build::Compat, added support for the 'verbose' parameter
    to Makefile.PL [spotted by Soren Andersen, fixed by Michael
    Schwern]

  - The Module::Build distribution now has a cryptographic 'SIGNATURE'
    file created by Module::Signature.

  - Added proper documentation for the subclass() method. [spotted by
    Jonathan Steinert]

  - Worked around a Config.pm bug in Red Hat 9 which prevented man
    pages from being installed in the correct places. [spotted by Ville
    Skytta]

  - Fixed a Module::Build::Compat bug in which setting INSTALLDIRS
    caused a crash. [spotted by Ilya Martynov]


  -Ken

Re: [Module-build-general] [PATCH] signing fixes

[Ken W. <ke...@ma...>]

On Saturday, September 6, 2003, at 11:11  AM, Dave Rolsky wrote:

> On Sat, 6 Sep 2003, Ken Williams wrote:
>
>> I was thinking that we might want to just add it to the MANIFEST,
>> actually.  I wonder whether we should.
>
> I don't know if it's worth it.  The MANIFEST has to be 100% in sync 
> with
> the distro for signing to work.  If the SIGNATURE file isn't in there,
> then other files may be missing too.
>

I think the SIGNATURE file needs to be a special case.  The user can't 
add it to the MANIFEST him/herself, because then

  * if SIGNATURE exists in the base directory, it won't be valid - and 
the only reason to create it would be to satisfy the hunger of 
manicopy().

  * if SIGNATURE doesn't exist in the base directory, then manicopy() 
will fail.

And since it needs to be added to the MANIFEST somehow, I think M::B 
has to do it.  This combination also means that the 'manifest' action 
will continue to work correctly too.

  -Ken

Re: [Module-build-general] [PATCH] signing fixes

[Dave R. <au...@ur...>]

On Sat, 6 Sep 2003, Dave Rolsky wrote:

> They maybe remove the local() bit and simply make distsign depend on
> distdir, and make distdir depend on distsign if $self->{properties}{sign}
> is true.

Actually, this isn't necessary.

There's a patch below my sig which fixes this.  It also still adds the
code to create a dumym SIGNATURE file in the distdir.

-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/


Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.186
diff -u -r1.186 Base.pm
--- lib/Module/Build/Base.pm    4 Sep 2003 20:47:55 -0000       1.186
+++ lib/Module/Build/Base.pm    6 Sep 2003 16:18:47 -0000
@@ -1475,8 +1475,9 @@

 sub ACTION_distsign {
   my ($self) = @_;
-  $self->depends_on('distdir') unless -d $self->dist_dir;
-  $self->_sign_dir($self->dist_dir);
+
+  local $self->{properties}{sign} = 1;
+  $self->depends_on('distdir');
 }

 sub ACTION_skipcheck {
@@ -1509,7 +1510,19 @@
     warn "No files found in MANIFEST - try running 'manifest' action?\n";
     return;
   }
-
+
+  if ($self->{properties}{sign}) {
+      warn "If you want to sign this distribution you need to include SIGNATURE in your MANIFEST file\n"
+         unless exists $dist_files->{SIGNATURE};
+
+      unless (-e 'SIGNATURE') {
+         # just make a dummy file so manicopy() doesn't balk below
+         open my $fh, ">SIGNATURE" or die "Cannot write to SIGNATURE: $!";
+         close $fh;
+         $self->add_to_cleanup('SIGNATURE');
+      }
+  }
+
   my $dist_dir = $self->dist_dir;
   $self->delete_filetree($dist_dir);
   $self->add_to_cleanup($dist_dir);

Re: [Module-build-general] [PATCH] signing fixes

[Dave R. <au...@ur...>]

On Sat, 6 Sep 2003, Ken Williams wrote:

> > The patch after my sig should fix the signing problems reported
> > earlier.
> > It also cleans up the interaction between the distsign and distdir
> > actions.  Previously, it's possible that _sign_dir() could've been
> > called
> > from both of them, which is silly.
>
> With this patch, calling "Build distsign" when the dist dir already
> exists will be a no-op.  It should just force a signing.

They maybe remove the local() bit and simply make distsign depend on
distdir, and make distdir depend on distsign if $self->{properties}{sign}
is true.

> I'd already added some code to CVS that removes the SIGNATURE file
> before signing, which means we don't need the overwrite => 1 flag, nor
> will we need to chmod() it.  I think removal is more portable than
> chmod() across platforms.

Yeah, that seems better.

> > Finally, I added a warning if we try to sign and SIGNATURE isn't in the
> > MANIFEST, since that is guaranteed to produce a bad signature.
>
> Good.
>
> I was thinking that we might want to just add it to the MANIFEST,
> actually.  I wonder whether we should.

I don't know if it's worth it.  The MANIFEST has to be 100% in sync with
the distro for signing to work.  If the SIGNATURE file isn't in there,
then other files may be missing too.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] [PATCH] signing fixes

[Ken W. <ke...@ma...>]

On Friday, September 5, 2003, at 05:55  PM, Dave Rolsky wrote:

> The patch after my sig should fix the signing problems reported 
> earlier.
> It also cleans up the interaction between the distsign and distdir
> actions.  Previously, it's possible that _sign_dir() could've been 
> called
> from both of them, which is silly.

With this patch, calling "Build distsign" when the dist dir already 
exists will be a no-op.  It should just force a signing.



> I've also added the "overwrite => 1" flag when calling M::S's sign()
> function, because otherwise would always be prompted, even though 
> they're
> usually overwriting a dummy file created earlier in the distdir action.

I'd already added some code to CVS that removes the SIGNATURE file 
before signing, which means we don't need the overwrite => 1 flag, nor 
will we need to chmod() it.  I think removal is more portable than 
chmod() across platforms.


> Finally, I added a warning if we try to sign and SIGNATURE isn't in the
> MANIFEST, since that is guaranteed to produce a bad signature.

Good.

I was thinking that we might want to just add it to the MANIFEST, 
actually.  I wonder whether we should.

  -Ken

[Module-build-general] [PATCH] signing fixes

[Dave R. <au...@ur...>]

The patch after my sig should fix the signing problems reported earlier.
It also cleans up the interaction between the distsign and distdir
actions.  Previously, it's possible that _sign_dir() could've been called
from both of them, which is silly.

I've also added the "overwrite => 1" flag when calling M::S's sign()
function, because otherwise would always be prompted, even though they're
usually overwriting a dummy file created earlier in the distdir action.

Finally, I added a warning if we try to sign and SIGNATURE isn't in the
MANIFEST, since that is guaranteed to produce a bad signature.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.181
diff -u -r1.181 Base.pm
--- lib/Module/Build/Base.pm	30 Aug 2003 20:46:07 -0000	1.181
+++ lib/Module/Build/Base.pm	5 Sep 2003 22:53:57 -0000
@@ -1454,13 +1454,19 @@
     return;
   }

+  my $sig_file = File::Spec->catfile($dir, 'SIGNATURE');
+  unless (-w $sig_file) {
+      chmod 0644, $sig_file
+	  or die "Cannot make $sig_file writeable: $!";
+  }
+
   # We protect the signing with an eval{} to make sure we get back to
   # the right directory after a signature failure.  Would be nice if
   # Module::Signature took a directory argument.

   my $start_dir = $self->cwd;
   chdir $dir or die "Can't chdir() to $dir: $!";
-  eval {Module::Signature::sign()};
+  eval {Module::Signature::sign(overwrite => 1)};
   my @err = $@ ? ($@) : ();
   chdir $start_dir or push @err, "Can't chdir() back to $start_dir: $!";
   die join "\n", @err if @err;
@@ -1468,8 +1474,9 @@

 sub ACTION_distsign {
   my ($self) = @_;
+
+  local $self->{properties}{sign} = 1;
   $self->depends_on('distdir') unless -d $self->dist_dir;
-  $self->_sign_dir($self->dist_dir);
 }

 sub ACTION_skipcheck {
@@ -1502,7 +1509,19 @@
     warn "No files found in MANIFEST - try running 'manifest' action?\n";
     return;
   }
-
+
+  if ($self->{properties}{sign}) {
+      warn "If you want to sign this distribution you need to include SIGNATURE in your MANIFEST file\n"
+	  unless exists $dist_files->{SIGNATURE};
+
+      unless (-e 'SIGNATURE') {
+	  # just make a dummy file so manicopy() doesn't balk below
+	  open my $fh, ">SIGNATURE" or die "Cannot write to SIGNATURE: $!";
+	  close $fh;
+	  $self->add_to_cleanup('SIGNATURE');
+      }
+  }
+
   my $dist_dir = $self->dist_dir;
   $self->delete_filetree($dist_dir);
   $self->add_to_cleanup($dist_dir);