headers
Johnny C. Lam | 1 Mar 2005 02:05
Picon

Re: [Module::Build] Patch to write .packlist files

On Mon, Feb 28, 2005 at 04:59:13PM -0600, Ken Williams wrote:
> Thanks Johnny, I've applied this for the next release.
> 
> Note that I had to move it about 8 lines higher, so that 'destdir' 
> prepending would work correctly.

Thanks!  I'm looking forward to the next release of Module::Build.

	Cheers,

	-- Johnny Lam <jlam <at> NetBSD.org>

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 0 comments |
headers
Warren Pollans | 9 Mar 2005 17:53
Picon

[Module::Build] non-standard file location

Hello,

I have a group of files that I would like to have Module::Build install 
to someplace other than where the scripts and modules go.

They live in the 'web' subdirectory of my build directory.  M::B will 
create the blib/web directory, but I haven't been able to figure out 
how to get M::B to put the files into blib/web?  If I put them there 
myself between the './Build' and './Build install' they get installed 
OK.

QUESTION#1: What's the 'web_files' equivalent of 'script_files' in my 
Build.PL below?
QUESTION#2: How can I get './Build diff' to diff these files (as well 
as the files in script directory) against the installed versions?

use Module::Build;
Module::Build->new(
     module_name  => 'DanceDB',
     license      => 'perl',
     install_path => {
             lib     => '/Users/warren/Library/Perl',
             script  => '/Users/warren/bin/cgi_bin',
            web    => '/tmp/web',
             },
     script_files => [ qw(
             script/dancedb.cgi
             script/dancedb-cdbi.cgi
             )],
)->create_build_script;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Warren Pollans | 9 Mar 2005 18:28
Picon

[Module::Build] [Partial Answer] non-standard file location

OK, I think I've found the answer to QUESTION#1 in M::B::Cookbook - I'm 
going to try it.

I'd still like an answer to Q#2 - and any other approaches to Q#1

Thanks again

+++++++++++++++++++++++++++++++++++

Hello,

I have a group of files that I would like to have Module::Build install 
to someplace other than where the scripts and modules go.

They live in the 'web' subdirectory of my build directory.  M::B will 
create the blib/web directory, but I haven't been able to figure out 
how to get M::B to put the files into blib/web?  If I put them there 
myself between the './Build' and './Build install' they get installed 
OK.

QUESTION#1: What's the 'web_files' equivalent of 'script_files' in my 
Build.PL below?
QUESTION#2: How can I get './Build diff' to diff these files (as well 
as the files in script directory) against the installed versions?

use Module::Build;
Module::Build->new(
     module_name  => 'DanceDB',
     license      => 'perl',
     install_path => {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Baker | 10 Mar 2005 10:08
Picon
Favicon

Re: [Module::Build] [Partial Answer] non-standard file location

RE: Q2

I asked a similar question a while ago and this was the answer:

use strict;
use Module::Build;

use constant INSTALL_DIR => '/path/to/my/nonstandard/lib';

# Ken Williams recommended this way to diff against INSTALL_DIR
my $package = Module::Build->subclass(code => <<'EOF');
  sub ACTION_diff {
    my $self = shift;
    local  <at> INC = ($self->install_destination('lib'),  <at> INC);
    $self->SUPER::ACTION_diff( <at> _);
  }
EOF

my $build = $package->new
    (
    module_name => 'MyModule',
    license     => 'perl',
    dist_version => '0.3',
    requires    => {
        'Test::More'  => '0.1',
        'HTML::Mason'  => '1.12',
    },
    install_base => &INSTALL_DIR,
    add_to_cleanup => [],
    );
(Continue reading)

Permalink | Reply | 0 comments |
headers
Warren Pollans | 10 Mar 2005 16:19
Picon

[Module::Build] [My SOLUTION] non-standard file location

Here's my solution to my questions below.  It's works, but it doesn't 
seem "right" - it requires too much knowledge of the M::B::Base code (I 
believe).  I've hijacked the ACTION_diff code and modified it. - it's 
specialized to unix (MacOSX 10.2.8).

[BUILD_DIR]$ cat Build.PL
use Module::Build;

##  build custom builder to do diff
##  ASSUMES all files can be compared with diff - no binaries
my $class = Module::Build->subclass(
         class => 'My::Builder',
         code  => q{
                 sub ACTION_diff {
                         my $self = shift;

                         ##  do ./Build
                         $self->depends_on('build');

                         ##  get diff flags: -c, etc
                         my  <at> flags =  <at> {$self->{args}{ARGV}};
                          <at> flags = 
$self->split_like_shell($self->{args}{flags} || '')
                                         unless  <at> flags;

                         ##  get mapping from blib to install dirs
                         my $installmap = $self->install_map;
                         delete $installmap->{read};
                         delete $installmap->{write};
(Continue reading)

Permalink | Reply | 0 comments |
headers
chromatic | 13 Mar 2005 00:48
Favicon

[Module::Build] Overriding Part of ACTION_test()

(I'm not a subscriber, so please Cc me on replies.)

I've written a Module::Build subclass that saves information about test
failures as well as the current testing environment.  My goal is to make
it easier for end-users to be able to report this information to
developers.

This isn't necessarily for cpantesters; I have in mind people
distributing applications to customers apart from the CPAN.

To make this work, the easiest approach seemed to be overriding parts of
Module::Build that aren't entirely public.  I'm looking for feedback in
three areas:

	- is there a cleaner way to do this?
	- is the idea something that Module::Build might support?
	- if yes to the previous question, what changes should I make to fit
with your ideas of how Module::Build ought to work?

The latest version of the code will always be at:

	http://wgz.org/chromatic/perl/Module-Build-TestReporter.tar.gz

This code is a proof of concept; I haven't released it officially and
this is the first public place I've mentioned it.

Thanks for any and all feedback,
-- c

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ken Williams | 15 Mar 2005 18:28
Favicon

Re: [Module::Build] Overriding Part of ACTION_test()


On Mar 12, 2005, at 5:48 PM, chromatic wrote:

> To make this work, the easiest approach seemed to be overriding parts 
> of
> Module::Build that aren't entirely public.

Typically this means we need to solidify and make public those areas of 
the API.  That's sort of the development model I tend to use (for 
better or worse) - create private-ish methods and make them public when 
someone asks for them to be public.

> I'm looking for feedback in
> three areas:
>
> 	- is there a cleaner way to do this?
> 	- is the idea something that Module::Build might support?
> 	- if yes to the previous question, what changes should I make to fit
> with your ideas of how Module::Build ought to work?

I've downloaded it and taken a very quick look, but haven't had time to 
really examine it.  It looks good, but the main problem is something 
that's not very easy to solve: since you're subclassing M::B, it means 
someone can't use both your value-added subclass and someone else's 
value-added subclass.  In other words, it would be nice to make this 
some kind of Mix-In or Decorator or Plugin thingy.

  -Ken

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
chromatic | 15 Mar 2005 20:20
Favicon

Re: [Module::Build] Overriding Part of ACTION_test()

On Tue, 2005-03-15 at 11:28 -0600, Ken Williams wrote:

> I've downloaded it and taken a very quick look, but haven't had time to 
> really examine it.  It looks good, but the main problem is something 
> that's not very easy to solve: since you're subclassing M::B, it means 
> someone can't use both your value-added subclass and someone else's 
> value-added subclass.  In other words, it would be nice to make this 
> some kind of Mix-In or Decorator or Plugin thingy.

I have a way to solve that part with Class::Roles (sort of a
decoration).  If everything else is reasonable, I'll put those pieces
together.

-- c

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 0 comments |
headers
Ken Williams | 16 Mar 2005 06:12
Favicon

[Module::Build] Ready for 0.2609?

Ready for 0.2609?

Also, I'm itching to get a beta release 0.27_01 out the door.  Maybe 
I'll just do it, unless someone knows of a good reason not to.

  -Ken

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 7 comments |
headers
Randy W. Sims | 16 Mar 2005 08:27

Re: [Module::Build] Ready for 0.2609?

Ken Williams wrote:
> Ready for 0.2609?

All ok on Debian.
Fails t/install.t #5 on Windows; the new packlist stuff. I haven't 
looked at it yet.

> Also, I'm itching to get a beta release 0.27_01 out the door.  Maybe 
> I'll just do it, unless someone knows of a good reason not to.

Same results as above.

I'm not sure I'm comfortable with the new code for properties. It's 
better than the original which I see from your comments that you were 
not happy with either. But the new code is really just a more 
complicated version of the original. I'm not sure I know a better 
solution. I'm not even completely sure I understand all that's going on 
there. I do know there is at least one problem which I posted about 
around a week and a half ago. I haven't done anything more since then 
because I've been nursing a cold. I guess it just doesn't feel right 
having property data stored as class data. Since this code is not yet in 
release, it seems good to explore options before getting locked in to a 
particular implementation.

Randy.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane