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