module-build-general

[Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

Module::Builders,

I just discovered install-base_relpaths, and for setting up new  
elements to simply be installed relative to whatever the install_base  
happens to be, it's very convenient. I'd like to see it documented in  
the cookbook. The attached patch adds a note about it there. Think  
you might let this be documented?

Thanks!

David

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Feb 16, 2006, at 21:33, David Wheeler wrote:

> I just discovered install-base_relpaths, and for setting up new  
> elements to simply be installed relative to whatever the  
> install_base happens to be, it's very convenient. I'd like to see  
> it documented in the cookbook. The attached patch adds a note about  
> it there. Think you might let this be documented?

Or perhaps better still, add_build_element could make it the default?  
That patch would look like this:

--- Base.pm	16 Feb 2006 22:06:21 -0800	1.546
+++ Base.pm	17 Feb 2006 11:28:54 -0800	
@@ -449,8 +449,9 @@


sub add_build_element {
-  my $self = shift;
-  push @{$self->build_elements}, shift;
+    my ($self, $elem) = @_;
+    $self->install_base_relpaths->{$elem} ||= [$elem];
+    push @{$self->build_elements}, $elem;

}

sub ACTION_config_data {

Thanks,

David

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Feb 17, 2006, at 11:30, David Wheeler wrote:

>> I just discovered install-base_relpaths, and for setting up new  
>> elements to simply be installed relative to whatever the  
>> install_base happens to be, it's very convenient. I'd like to see  
>> it documented in the cookbook. The attached patch adds a note  
>> about it there. Think you might let this be documented?
>
> Or perhaps better still, add_build_element could make it the  
> default? That patch would look like this:
>
> --- Base.pm	16 Feb 2006 22:06:21 -0800	1.546
> +++ Base.pm	17 Feb 2006 11:28:54 -0800	
> @@ -449,8 +449,9 @@
>
>
> sub add_build_element {
> -  my $self = shift;
> -  push @{$self->build_elements}, shift;
> +    my ($self, $elem) = @_;
> +    $self->install_base_relpaths->{$elem} ||= [$elem];
> +    push @{$self->build_elements}, $elem;
>
> }
>
> sub ACTION_config_data {

Any comments on these suggestions? Maybe a different method that does  
both of these actions would be welcomed?

sub add_build_element_with_path {
     my ($self, $elem) = @_;
     $self->add_build_element($elem);
     $self->install_base_relpaths->{$elem} ||= [$elem];
}

???

Thanks,

David

Re: [Module::Build] Document install_base_relpaths

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

On Mar 3, 2006, at 3:44 PM, David Wheeler wrote:

> On Feb 17, 2006, at 11:30, David Wheeler wrote:
>
>>> I just discovered install-base_relpaths, and for setting up new  
>>> elements to simply be installed relative to whatever the  
>>> install_base happens to be, it's very convenient. I'd like to see  
>>> it documented in the cookbook. The attached patch adds a note  
>>> about it there. Think you might let this be documented?
>>
>> Or perhaps better still, add_build_element could make it the  
>> default? That patch would look like this:
>>
>> --- Base.pm	16 Feb 2006 22:06:21 -0800	1.546
>> +++ Base.pm	17 Feb 2006 11:28:54 -0800	
>> @@ -449,8 +449,9 @@
>>
>>
>> sub add_build_element {
>> -  my $self = shift;
>> -  push @{$self->build_elements}, shift;
>> +    my ($self, $elem) = @_;
>> +    $self->install_base_relpaths->{$elem} ||= [$elem];
>> +    push @{$self->build_elements}, $elem;
>>
>> }
>>
>> sub ACTION_config_data {
>
> Any comments on these suggestions? Maybe a different method that  
> does both of these actions would be welcomed?
>
> sub add_build_element_with_path {
>     my ($self, $elem) = @_;
>     $self->add_build_element($elem);
>     $self->install_base_relpaths->{$elem} ||= [$elem];
> }

Sorry, I forgot to comment on this after our IRC conversation.

The patch doesn't quite make sense, because the stuff in  
build_elements isn't the same kind of stuff that's in  
install_base_relpaths.  In build_elements we have stuff that's going  
to be gathered from the distribution, processed in some way, then put  
into the blib/ staging area:

   qw(PL support pm xs pod script)

where each has a couple of corresponding methods (e.g. find_pm_files,  
process_pm_files) to actually do the work.

But in install_base_relpaths, we have stuff that maps from the blib/  
staging area to the default install_base locations on disk:

     {
      lib     => ['lib', 'perl5'],
      arch    => ['lib', 'perl5', $arch],
      bin     => ['bin'],
      script  => ['bin'],
      bindoc  => ['man', 'man1'],
      libdoc  => ['man', 'man3'],
      binhtml => ['html'],
      libhtml => ['html'],
     };

So notice that there's no correspondence between the keys of these  
two hashes - it wouldn't therefore make any sense in the default case  
to put an entry in install_base_relpaths just because there's one in  
build_elements.

In general, with custom stuff in a distro, you first specify how it  
gets mapped to blib/, then how it gets mapped to installation  
directories.

  -Ken

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Mar 4, 2006, at 09:11, Ken Williams wrote:

> In general, with custom stuff in a distro, you first specify how it  
> gets mapped to blib/, then how it gets mapped to installation  
> directories.

Yes, but I think that a reasonable default would be "copy all of the  
files from the distribution directory named for the element to the  
same named directory under the install base." That's what I'm running  
into when, for example, I want to install Mason components. They  
don't need to be processed at all, just copied from comp to blib/comp  
during ./Build, and from blib/comp to install_base/comp during ./ 
Build install.

That's why I was suggesting a separate method, so that it could be  
independent. But ultimately what's happening for me is that I want to  
make sure that the contents of the comp directory are installed in  
comp relative to the install base, even if it should change during  
the build process.

So I'm thinking something like this:

   sub add_build_dir {
       my ($self, $dir) = @_;
       die "What the?" unless -d $dir;
       $self->add_build_element($dir);
       $self->install_base_relpaths->{$elem} ||= [$elem];
       no strict 'refs';
       *{ref $self . "::process_$dir\_files"} = sub {
           my self = shift;
           my $files = $self->find_files_in_dir($dir);
           while (my ($file, $dest) = each %$files) {
               $self->copy_if_modified(
                   from => $file,
                   to => File::Spec->catfile($self->blib, $dest)
               );
           }
       };
   }

Only perhaps less magical. Do you see what I'm getting at?

Best,

David

Re: [Module::Build] Document install_base_relpaths

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Mar 4, 2006, at 09:11, Ken Williams wrote:
> 
>> In general, with custom stuff in a distro, you first specify how it  
>> gets mapped to blib/, then how it gets mapped to installation  
>> directories.
> 
> 
> Yes, but I think that a reasonable default would be "copy all of the  
> files from the distribution directory named for the element to the  same 
> named directory under the install base." That's what I'm running  into 
> when, for example, I want to install Mason components. They  don't need 
> to be processed at all, just copied from comp to blib/comp  during 
> ./Build, and from blib/comp to install_base/comp during ./ Build install.
> 
> That's why I was suggesting a separate method, so that it could be  
> independent. But ultimately what's happening for me is that I want to  
> make sure that the contents of the comp directory are installed in  comp 
> relative to the install base, even if it should change during  the build 
> process.
> 
> So I'm thinking something like this:
> 
>   sub add_build_dir {
>       my ($self, $dir) = @_;
>       die "What the?" unless -d $dir;
>       $self->add_build_element($dir);
>       $self->install_base_relpaths->{$elem} ||= [$elem];
>       no strict 'refs';
>       *{ref $self . "::process_$dir\_files"} = sub {
>           my self = shift;
>           my $files = $self->find_files_in_dir($dir);
>           while (my ($file, $dest) = each %$files) {
>               $self->copy_if_modified(
>                   from => $file,
>                   to => File::Spec->catfile($self->blib, $dest)
>               );
>           }
>       };
>   }
> 
> Only perhaps less magical. Do you see what I'm getting at?

Does this work with 0.27x ?

IIUC, the desired behavior is that by saying:

my $build = Module::Build->new(
   ...
   conf_files => { 'conf/myconf' => 'conf/myconf' },
};

$build->add_build_dir('conf');

The 'conf' files will be automatically installed when an 'install_base' 
is supplied? Eg.

   ./Build install --install-base ~

rather than requiring an explicit install-path

   .Build install --install-base ~ --install-path conf=~/conf

But the supplied patches don't do anything because ->install_types() 
still don't know about 'conf' files.

Also, would something similar be done for 'prefix'? Where would the 
default location be? Somewhere like:

   "$prefix/share/$dist_name/$elem"

Or did I miss the intent?

Randy.

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Mar 4, 2006, at 13:40, Randy W. Sims wrote:

>>   sub add_build_dir {
>>       my ($self, $dir) = @_;
>>       die "What the?" unless -d $dir;
>>       $self->add_build_element($dir);
>>       $self->install_base_relpaths->{$elem} ||= [$elem];
>>       no strict 'refs';
>>       *{ref $self . "::process_$dir\_files"} = sub {
>>           my self = shift;
>>           my $files = $self->find_files_in_dir($dir);
>>           while (my ($file, $dest) = each %$files) {
>>               $self->copy_if_modified(
>>                   from => $file,
>>                   to => File::Spec->catfile($self->blib, $dest)
>>               );
>>           }
>>       };
>>   }
>> Only perhaps less magical. Do you see what I'm getting at?
>
> Does this work with 0.27x ?

I don't think that there's a find_files_in_dir method (it's in my  
subclass), and I just typed it into email, but it should work modulo  
a few typos.

> IIUC, the desired behavior is that by saying:
>
> my $build = Module::Build->new(
>   ...
>   conf_files => { 'conf/myconf' => 'conf/myconf' },
> };

Well, with the find_files_in_dir() method, you wouldn't need to  
specify conf_files. It would just copy all of the files in the conf/  
directory.

> $build->add_build_dir('conf');
>
> The 'conf' files will be automatically installed when an  
> 'install_base' is supplied? Eg.
>
>   ./Build install --install-base ~
>
> rather than requiring an explicit install-path
>
>   .Build install --install-base ~ --install-path conf=~/conf

Right.

> But the supplied patches don't do anything because ->install_types 
> () still don't know about 'conf' files.

Well, this works perfectly for me in my subclass. This is in new:

     # Add www element and install path.
     $self->add_build_element('www');
     $self->install_base_relpaths->{www} = ['www'];

And later in the subclass:

sub process_www_files {
     my $self  = shift;
     my $files = $self->find_files_in_dir('www');
     while (my ($file, $dest) = each %$files) {
         $self->copy_if_modified(
             from => $file,
             to => File::Spec->catfile($self->blib, $dest)
         );
     }
}

But I also force install_base to always be set.

> Also, would something similar be done for 'prefix'? Where would the  
> default location be? Somewhere like:
>
>   "$prefix/share/$dist_name/$elem"
>
> Or did I miss the intent?

I don't know. I assume that people generally know where they want  
stuff, though. Maybe you have an etc dir, in which case, if you're  
installing to /usr/local, the files would be put into /usr/local/etc.

Does that make sense?

Thanks,

David

Re: [Module::Build] Document install_base_relpaths

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Mar 4, 2006, at 13:40, Randy W. Sims wrote:
> 
>>>   sub add_build_dir {
[...]
>>>       };
>>>   }
>>> Only perhaps less magical. Do you see what I'm getting at?
>>
>> Does this work with 0.27x ?
> 
> I don't think that there's a find_files_in_dir method (it's in my 
> subclass), and I just typed it into email, but it should work modulo a 
> few typos.

The reason I ask is that I didn't see any affect from applying any of 
the proposed patches, and I want to make sure it's not a flaw in my 
understanding. For an author-defined element to get installed, it must 
end up in ->install_types()

sub install_types {
   my $self = shift;
   my %types = (%{$self->install_path},
                %{$self->install_sets($self->installdirs)});
   return sort keys %types;
}

The only way to update that is to explicitly set install_path either on 
the commandline or programatically or to modify the install_set 
programatically. The patches provided don't do either, so the functions 
don't seem to have any affective use... Unless I'm misunderstanding 
(which is perfectly probable).

>> IIUC, the desired behavior is that by saying:
>>
>> my $build = Module::Build->new(
>>   ...
>>   conf_files => { 'conf/myconf' => 'conf/myconf' },
>> };
> 
> Well, with the find_files_in_dir() method, you wouldn't need to specify 
> conf_files. It would just copy all of the files in the conf/ directory.

If it were added, I'd like to see it work either way.

>> $build->add_build_dir('conf');
>>
>> The 'conf' files will be automatically installed when an 
>> 'install_base' is supplied? Eg.
>>
>>   ./Build install --install-base ~
>>
>> rather than requiring an explicit install-path
>>
>>   .Build install --install-base ~ --install-path conf=~/conf
> 
> Right.
> 
>> But the supplied patches don't do anything because ->install_types() 
>> still don't know about 'conf' files.
> 
> Well, this works perfectly for me in my subclass. This is in new:
> 
>     # Add www element and install path.
>     $self->add_build_element('www');
>     $self->install_base_relpaths->{www} = ['www'];
> 
> And later in the subclass:
> 
> sub process_www_files {
>     my $self  = shift;
>     my $files = $self->find_files_in_dir('www');
>     while (my ($file, $dest) = each %$files) {
>         $self->copy_if_modified(
>             from => $file,
>             to => File::Spec->catfile($self->blib, $dest)
>         );
>     }
> }
> 
> But I also force install_base to always be set.
> 
>> Also, would something similar be done for 'prefix'? Where would the 
>> default location be? Somewhere like:
>>
>>   "$prefix/share/$dist_name/$elem"
>>
>> Or did I miss the intent?
> 
> I don't know. I assume that people generally know where they want stuff, 
> though. Maybe you have an etc dir, in which case, if you're installing 
> to /usr/local, the files would be put into /usr/local/etc.
> 
> Does that make sense?

I think I see what you're wanting, and I can see several ways of doing 
it fairly simply, but I'm reluctant to do it now. I'd rather wait until 
0.28 is out. add_build_element() can't be changed; it would change the 
behavior of existing distros, and it was discussed some time back that 
author defined build elements only get installed when supplied with 
explicit paths.

I'm also reluctant to document install_base_relpath() & companion 
prefix_relpath() as is because I don't like methods that return 
references to internal data structures, preferring explicit getter & 
setter methods. The behavior you're looking for is one good example of a 
change that might be easily accomplished by changing the underlying data 
structure. (Some issues with the manpages & html docs are another 
parallel issue that could be tidied up with changes to the same data 
structure.)

Maybe we can change them to accept a new value, and then document them. 
that would be a simple and effective interim solution:

   $self->install_base_relpath();  # deprecated; returns reference to 
internal data
   $self->install_base_relpath($elem); # returns path for $elem
   $self->install_base_relpath($elem => $new_val); # sets path for $elem


For a future release, maybe we could provide something more generic. 
Issues related to installing custom items have come up a lot on this 
list and others, so maybe some easy way to provide for the common cases 
would be appropriate?

$builder->auto_build_elements( element => 'conf',
                                filter => 'conf/*.conf',
                                install_relpath => 'conf' );

$builder->auto_build_elements( element => 'conf',
                                process => \&process_conf_files);

Along with associated arguments to the M::B->new() constructor.

Arguments:
  element => the name of the element type

  filter  => a file glob of files to process
  process => alternative to 'filter' above

  install_relpath      => sets default for both install_base_relpath & 
prefix_relpath
  install_base_relpath => sets default for install_base_relpath
  prefix_relpath       => sets default for prefix_relpath


Randy.

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Mar 6, 2006, at 17:51, Randy W. Sims wrote:

> The reason I ask is that I didn't see any affect from applying any  
> of the proposed patches, and I want to make sure it's not a flaw in  
> my understanding. For an author-defined element to get installed,  
> it must end up in ->install_types()
>
> sub install_types {
>   my $self = shift;
>   my %types = (%{$self->install_path},
>                %{$self->install_sets($self->installdirs)});
>   return sort keys %types;
> }
>
> The only way to update that is to explicitly set install_path  
> either on the commandline or programatically or to modify the  
> install_set programatically. The patches provided don't do either,  
> so the functions don't seem to have any affective use... Unless I'm  
> misunderstanding (which is perfectly probable).

No, I think you probably have it. I'm enforcing the setting of  
install_base in my subclass.

>> Well, with the find_files_in_dir() method, you wouldn't need to  
>> specify conf_files. It would just copy all of the files in the  
>> conf/ directory.
>
> If it were added, I'd like to see it work either way.

Either way?

> I think I see what you're wanting, and I can see several ways of  
> doing it fairly simply, but I'm reluctant to do it now. I'd rather  
> wait until 0.28 is out. add_build_element() can't be changed; it  
> would change the behavior of existing distros, and it was discussed  
> some time back that author defined build elements only get  
> installed when supplied with explicit paths.

Yeah, that's why I was suggesting a new method.

> I'm also reluctant to document install_base_relpath() & companion  
> prefix_relpath() as is because I don't like methods that return  
> references to internal data structures, preferring explicit getter  
> & setter methods.

Agreed. I only suggested it because install_path is documented in the  
cookbook:

   $build->install_path->{conf} || $installation_path;

There probably ought to be accessors for that, too.

> The behavior you're looking for is one good example of a change  
> that might be easily accomplished by changing the underlying data  
> structure. (Some issues with the manpages & html docs are another  
> parallel issue that could be tidied up with changes to the same  
> data structure.)

Yes, I recall that you just fixed some issues with manpages and html  
when install_base is set.

> Maybe we can change them to accept a new value, and then document  
> them. that would be a simple and effective interim solution:
>
>   $self->install_base_relpath();  # deprecated; returns reference  
> to internal data
>   $self->install_base_relpath($elem); # returns path for $elem
>   $self->install_base_relpath($elem => $new_val); # sets path for  
> $elem

Sure.

> For a future release, maybe we could provide something more  
> generic. Issues related to installing custom items have come up a  
> lot on this list and others, so maybe some easy way to provide for  
> the common cases would be appropriate?

Yes, that's exactly what I was trying to get at.

> $builder->auto_build_elements( element => 'conf',
>                                filter => 'conf/*.conf',
>                                install_relpath => 'conf' );
>
> $builder->auto_build_elements( element => 'conf',
>                                process => \&process_conf_files);

Yes, that's nice.

> Along with associated arguments to the M::B->new() constructor.
>
> Arguments:
>  element => the name of the element type
>
>  filter  => a file glob of files to process

Or maybe a File::Find wanted subref?

>  process => alternative to 'filter' above
>
>  install_relpath      => sets default for both install_base_relpath  
> & prefix_relpath
>  install_base_relpath => sets default for install_base_relpath
>  prefix_relpath       => sets default for prefix_relpath

Yep, I think you're right on it. Phew! I'm glad to be understood! :-)

Best,

David

Re: [Module::Build] Document install_base_relpaths

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Mar 6, 2006, at 17:51, Randy W. Sims wrote:
>> Maybe we can change them to accept a new value, and then document  
>> them. that would be a simple and effective interim solution:
>>
>>   $self->install_base_relpath();  # deprecated; returns reference  to 
>> internal data
>>   $self->install_base_relpath($elem); # returns path for $elem
>>   $self->install_base_relpath($elem => $new_val); # sets path for  $elem
> 
> Sure.

I know we're trying to push 0.28 out, but the whole issue of supporting 
custom install types is nagging at me. I've documented and beefed up the 
interface for install_base_relpaths(), prefix_relpaths(), and 
install_path(). And improved the install_types() method to recognize 
elements added from the afore mentioned methods. Example below.

David, could you let me know if this provides a solid interim solution 
to the issues you've brought up. The repository has now moved to a 
subversion repository at <https://svn.perl.org/modules/Module-Build/> if 
you want to check it out.

Thanks,
Randy.

use Module::Build;
my $build_class = Module::Build->subclass(code => <<'---');

   sub new {
     my $package = shift;
     my $self = $package->SUPER::new(@_);
     $self->add_build_element('config');
     $self->install_base_relpaths(config => 'etc');
     $self->prefix_relpaths($self->installdirs, config => 'etc');
     return $self;
   }

   sub find_config_files {
     my $self = shift;
     return { 'etc/sample.conf' => 'config/Foo.conf' };
   }

   sub _warn_if_no_config {
     my $self = shift;
     $self->log_warn( "Config files will not be installed.\n" )
       unless $self->install_base()
           || $self->prefix()
           || $self->install_path('config');
   }

   sub ACTION_install {
     my $self = shift;
     $self->_warn_if_no_config();
     $self->SUPER::ACTION_install(@_);
   }

   sub ACTION_fakeinstall {
     my $self = shift;
     $self->_warn_if_no_config();
     $self->SUPER::ACTION_fakeinstall(@_);
   }

---

my $builder = $build_class->new(
     module_name => 'Foo',
     license     => 'perl',
);

$builder->create_build_script();

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Apr 6, 2006, at 03:54, Randy W. Sims wrote:

> David, could you let me know if this provides a solid interim =20
> solution to the issues you've brought up. The repository has now =20
> moved to a subversion repository at <https://svn.perl.org/modules/=20
> Module-Build/> if you want to check it out.

Yeah, looks great. I was able to patch my subclass thusly:

Index: Base.pm
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- Base.pm	(revision 2767)
+++ Base.pm	(working copy)
@@ -473,15 +473,15 @@
      }
      # Prevent installation into lib/perl5. We just want lib'.
-    $self->install_base_relpaths->{lib} =3D ['lib'];
+    $self->install_base_relpaths(lib =3D> 'lib');
      # Add www element and install path.
      $self->add_build_element('www');
-    $self->install_base_relpaths->{www} =3D ['www'];
+    $self->install_base_relpaths(www =3D> 'www');
      # Add config file element and install path.
      $self->add_build_element('conf');
-    $self->install_base_relpaths->{conf} =3D ['conf'];
+    $self->install_base_relpaths(conf =3D> 'conf');
      # Prompts.
      for my $class ( reverse Class::ISA::self_and_super_path(ref =20
$self) ) {

And it just worked. Sweet=97thanks!

David=

Re: [Module::Build] Document install_base_relpaths

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Apr 6, 2006, at 03:54, Randy W. Sims wrote:
> 
>> David, could you let me know if this provides a solid interim  
>> solution to the issues you've brought up. The repository has now  
>> moved to a subversion repository at <https://svn.perl.org/modules/ 
>> Module-Build/> if you want to check it out.
> 
> 
> Yeah, looks great. I was able to patch my subclass thusly:

Great. besides making the methods public and documenting them, the 
bigger change was one you don't see: During install it now knows to 
install the custom type whereas before it would not install them unless 
you specified an explicit --install-path or did some trickery under the 
hood. Eg. setting install_base_relpath and giving the --install-base 
option did nothing when installing.

Thanks,
Randy.

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Apr 6, 2006, at 10:53, Randy W. Sims wrote:

> Great. besides making the methods public and documenting them, the  
> bigger change was one you don't see: During install it now knows to  
> install the custom type whereas before it would not install them  
> unless you specified an explicit --install-path or did some  
> trickery under the hood. Eg. setting install_base_relpath and  
> giving the --install-base option did nothing when installing.

So if I don't set install-path or install_base, where will it be  
installed? I thought that I needed to write process_[element]_files()  
to set it up to do the right thing. For example, for my "www"  
element, I have this method:

sub process_www_files {
     my $self  = shift;
     my $files = $self->find_www_files;
     while (my ($file, $dest) = each %$files) {
         $self->copy_if_modified(
             from => $file,
             to => File::Spec->catfile($self->blib, $dest)
         );
     }
}

Do I no longer need that?

Best,

Daviid

Re: [Module::Build] Document install_base_relpaths

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Apr 6, 2006, at 10:53, Randy W. Sims wrote:
> 
>> Great. besides making the methods public and documenting them, the 
>> bigger change was one you don't see: During install it now knows to 
>> install the custom type whereas before it would not install them 
>> unless you specified an explicit --install-path or did some trickery 
>> under the hood. Eg. setting install_base_relpath and giving the 
>> --install-base option did nothing when installing.
> 
> So if I don't set install-path or install_base, where will it be 
> installed?

If 'install_path' is set, elements will be installed to the set location.

If 'install_base' is set, and the author provides a relpath via 
install_base_relpath(), elements will be installed to install_base/relpath.

If 'prefix' is set, and the author provides a relpath via 
prefix_relpath(), elements will be installed to prefix/relpath.

Otherwise it will not be installed.

The changes I made allow the above to work without further tinkering 
with the internals by authors.

> I thought that I needed to write process_[element]_files() to 
> set it up to do the right thing. For example, for my "www" element, I 
> have this method:
> 
> sub process_www_files {
>     my $self  = shift;
>     my $files = $self->find_www_files;
>     while (my ($file, $dest) = each %$files) {
>         $self->copy_if_modified(
>             from => $file,
>             to => File::Spec->catfile($self->blib, $dest)
>         );
>     }
> }
> 
> Do I no longer need that?

None of my changes affect the code above in any way. Although, as 
written, I think the code above is redundant. IIRC, the default 
processing does exactly what your process_www_files() does as long as 
you supply the find_www_files. But, again, that has nothing to do with 
any changes I've recently made.

Regards,
Randy.

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Apr 7, 2006, at 15:52, Randy W. Sims wrote:

> If 'install_path' is set, elements will be installed to the set  
> location.

Right, sure.

> If 'install_base' is set, and the author provides a relpath via  
> install_base_relpath(), elements will be installed to install_base/ 
> relpath.

Perfect.

> If 'prefix' is set, and the author provides a relpath via  
> prefix_relpath(), elements will be installed to prefix/relpath.

Oh, huh. So I need to specify both install_base_relpath *and*  
prefix_relpath? Why wouldn't both be covered by a single method call?

> Otherwise it will not be installed.

So as a module author, if I require that it be installed, I just need  
to make sure that both install_base_relpath and prefix_relpath are  
specified and that the user use either install_path, install_base, or  
prefix, right?

> The changes I made allow the above to work without further  
> tinkering with the internals by authors.

That's good. :-)

> None of my changes affect the code above in any way. Although, as  
> written, I think the code above is redundant. IIRC, the default  
> processing does exactly what your process_www_files() does as long  
> as you supply the find_www_files. But, again, that has nothing to  
> do with any changes I've recently made.

Oh, really? /me tries that...yep, sure enough. Thanks, Randy!

Best,

David

Re: [Module::Build] Document install_base_relpaths

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Apr 7, 2006, at 15:52, Randy W. Sims wrote:
> 
>> If 'install_path' is set, elements will be installed to the set location.
> 
> Right, sure.
> 
>> If 'install_base' is set, and the author provides a relpath via 
>> install_base_relpath(), elements will be installed to 
>> install_base/relpath.
> 
> Perfect.
> 
>> If 'prefix' is set, and the author provides a relpath via 
>> prefix_relpath(), elements will be installed to prefix/relpath.
> 
> Oh, huh. So I need to specify both install_base_relpath *and* 
> prefix_relpath? Why wouldn't both be covered by a single method call?

Yes, since prefix and install_base are different path layouts, it makes 
sense to require them to be set separately so that the author thinks 
about the different layouts.

>> Otherwise it will not be installed.
> 
> So as a module author, if I require that it be installed, I just need to 
> make sure that both install_base_relpath and prefix_relpath are 
> specified and that the user use either install_path, install_base, or 
> prefix, right?

Right. See in my previous example[1] how I checked for those settings 
and issued a warning to the user when none were supplied.

Randy.

1. 
<http://article.gmane.org/gmane.comp.lang.perl.modules.module-build/3607/>

Re: [Module::Build] Document install_base_relpaths

[David W. <da...@ki...>]

On Apr 7, 2006, at 18:47, Randy W. Sims wrote:

> Yes, since prefix and install_base are different path layouts, it  
> makes sense to require them to be set separately so that the author  
> thinks about the different layouts.

Okay.

> Right. See in my previous example[1] how I checked for those  
> settings and issued a warning to the user when none were supplied.

Right, I see that, now. Maybe that example should be added to the  
cookbook, then? My module currently requires install_base, so I don't  
need to worry about prefix_relpaths.

Thanks, Randy, this is great!

Best,

David

Re: [Module::Build] Document install_base_relpaths

[Stephen A. <spa...@gm...>]

Hi,

This feature is one of the primary reasons I subclassed Module::Build
and made App::Build (on CPAN).  I am looking for the right way to
contribute this feature to Module::Build itself because I think it belongs
there.

http://sourceforge.net/mailarchive/forum.php?thread_id=3D9741242&forum_id=
=3D10905
http://search.cpan.org/~spadkins/App-Build/lib/App/Build.pm

I guess I will wait until the topic comes up again after 0.28.

Stephen

On 3/6/06, Randy W. Sims <ml...@th...> wrote:
...
> > I don't know. I assume that people generally know where they want stuff=
,
> > though. Maybe you have an etc dir, in which case, if you're installing
> > to /usr/local, the files would be put into /usr/local/etc.
> >
> > Does that make sense?
>
> I think I see what you're wanting, and I can see several ways of doing
> it fairly simply, but I'm reluctant to do it now. I'd rather wait until
> 0.28 is out. add_build_element() can't be changed; it would change the
> behavior of existing distros, and it was discussed some time back that
> author defined build elements only get installed when supplied with
> explicit paths.
...