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

Re: [Module::Build] M::B and version.pm

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

Ken Williams wrote:
> 
> On Feb 22, 2006, at 2:54 PM, John Peacock wrote:
> 
>> If Ken and/or Randy want to tell me whether they want to hold 0.28 for 
>> the fully debugged and thought out version object support, I will do 
>> what I can to get that working.
> 
> I'm quite happy to wait until after 0.28 to address it.

Me too! If it's ok, I'm going to mark all my version related mails done, 
  and we'll start fresh on 0.28? If none are pressing errors for this 
release?

John, I appreciate your perseverance and all the advice and help on this 
issue.

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

[Module::Build] Re: Module::Build + Apache2 oddity

[Randy W. S. <Ra...@Th...>]

Tyler MacDonald wrote:
> I have a function that does this to get database settings, to test an
> apache2 handler that uses a database:
> 
> sub test_db {
>     my $build = Apache::TestMB->current;
>     return unless $build->notes('DBI_DSN');
>     return map {
>         defined $build->notes($_) ? $build->notes($_) : ''
>     } qw(DBI_DSN DBI_USER DBI_PASS);
> }
> 
> When I grab these values from within extra.last.conf.in, the function
> returns successfully and gives me the right settings right away. However,
> Apache::Test's apache2 times out waiting for the server to start. I get the
> same result with Module::Build->current.
> 
> When I set these in my extra.conf.last.in manually, everything works and my
> tests pass.
> 
> I'm kind of confused as to how invoking a Module::Build object could cause
> the server to hang long after the object has been destroyed. Any ideas?
> 
> For now, I'm just doing to do() the _build/notes file to get this config
> data.

Hmm, not sure I know enough about web servers to help out. Which part of 
the above method is causing it to hang? If you take out the call to 
notes, so it only loads the MB object does it succeed? Can you construct 
a simple test case that exhibits the problem?

Randy.

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] [PATCH] Missing META.yml fields

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

Chris Dolan wrote:
> If you use the "dist_name" style of Build.PL instead of "module_name", 
> then you need to include the "dist_abstract" field too, or you will see 
> the following error when running "Build distmeta":
> 
>   ERROR: Missing required field 'abstract' for META.yml
> 
> This is very misleading because it's the "dist_abstract" field that's 
> missing, not "abstract".  The following simple patch changes the error 
> message.  I've confirmed that with the patch it now says:
> 
>   ERROR: Missing required field 'dist_abstract' for META.yml
> 
> but I haven't tested any fields other than "abstract".
> 
> Chris
> 
> diff -u -r1.552 Base.pm
> --- lib/Module/Build/Base.pm    4 Mar 2006 03:59:28 -0000       1.552
> +++ lib/Module/Build/Base.pm    5 Mar 2006 20:45:41 -0000

Thanks, applied.

Randy.

Re: [Module::Build] [PATCH] missed this part when adding Tie::CPHash

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

Yitzchak Scott-Thoennes wrote:
> This doesn't seem to have made it to the list; resending.

The sourceforge mailing lists seem to have been off-line most of the 
weekend.

> --- Module-Build-0.27_08/t/lib/MBTest.pm.orig	2006-03-03 19:27:57.000000000 -0800
> +++ Module-Build-0.27_08/t/lib/MBTest.pm	2006-03-05 11:28:21.187500000 -0800

Thanks, I've applied this.

Randy.

Re: [Module::Build] should Pod::Readme vs. Pod::Text for README creation be a feature?

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

Yitzchak Scott-Thoennes wrote:
> On Sat, Mar 04, 2006 at 11:28:34PM -0500, Randy W. Sims wrote:
>> Yitzchak Scott-Thoennes wrote:
>>> On Sat, Mar 04, 2006 at 10:06:19PM -0500, Randy W. Sims wrote:
>>>
>>>> Yitzchak Scott-Thoennes wrote:
>>>>
>>>>> Just as META.yml can be forced to build with or without YAML by setting
>>>>> the YAML_feature, shouldn't README creation depend on a feature?
>>>>>
>>>>> The other discrepancy is that Pod::Readme is recommended but YAML is
>>>>> not; seems to me both or neither should be listed in recommends: in
>>>>> META.yml.  Same with the other feature-enabling modules.  If not,
>>>>> what are the criteria for what goes in recommends: and what doesn't?
>>>> The requirement for creating README can't be properly expressed with 
>>>> current limitations; It depends on (Pod::Readme || Pod::Text). The best 
>>>> we can do is recommend one or both.
>>>
>>> Pod::Text has been in the core since 5.002.  But even if it wasn't,
>>> Pod::Readme makes a better README file; Pod::Text is just a fallback.
>>> Hence the recommendation.
>>>
>>> I see a parallel with YAML; YAML makes a better META.yml than the
>>> fallback, so it should be recommended.
>> Sorry, I guess I forgot about Pod::Text being in core. I can see the 
>> parallel. Would the attached patch be ok?
> 
> I'd rather see YAML added to recommends than Pod::Readme removed.

That's not what you said in your initial mail: ;)

 >>>Yitzchak Scott-Thoennes wrote:
> Just as META.yml can be forced to build with or without YAML by setting
> the YAML_feature, shouldn't README creation depend on a feature?
<<<

> Seems to me they both fit the mission statement of recommends.

I guess it could go either way. I tend to favor features because it 
gives the author has a chance to describe to the user exactly what 
functionality is disabled because of which missing dependencies.

> (But I'm wishing more and more Module::Build had started out as
> separate user and author distributions.)

This has come up before, though it's been a while. And with some of the 
recent discussion, I've been thinking about more myself for the last 
week or so. It could be done I suppose, just installing stubs for the 
authoring actions that used the developer bundle if present or printed 
instructions if not. Maybe we can put this on the wish-list, at least 
for discussion, for 0.32 or so (after XS improvements & recursive builds).

>> Can I also suggest a slight rewording of the auto_features descriptions? 
>> ( s/^Can (.)/\u$1/ )
> 
> Fine with me.  I went to check how config_data displays these and was
> a little surprised to see that it didn't.

Yeah, I think this should go on the TODO list, unless someone wants to 
provide a patch?

Randy.

Re: [Module::Build] Version 0.58 of YAML is installed, but we need version < 0.49

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

Andreas J. Koenig wrote:
>   [...]
>   Module-Build-0.2612/t/XSTest/lib/XSTest.xs
>   Module-Build-0.2612/t/XSTest/MANIFEST
>   Module-Build-0.2612/t/XSTest/test.pl
>   WARNING: This key is not certified with a trusted signature!
>   Primary key fingerprint: ADCB DB05 B40E B2A2 A555  5462 82BB CC04 B7EF 9476
> 
>     CPAN.pm: Going to build K/KW/KWILLIAMS/Module-Build-0.2612.tar.gz
> 
>   # running Build.PL
>   /home/src/perl/repoperls/installed-perls/perl/p4pqpmS/perl-5.8.0@27350/bin/perl -Ilib Build.PL
>   Checking whether your kit is complete...
>   Looks good
>   Feature 'YAML_support' disabled because of the following prerequisite failures:
>    * Version 0.58 of YAML is installed, but we need version < 0.49
> 
> 
> If this is not a bug, maybe a comment should be added in the Build.PL,
> why it is needed.


This was initially due to bugs in YAML version 0.49x. It has been fixed 
in M::B developer releases for a while, but I guess it never made the 
way back to the 0.26x releases. Ken, are you planning to release another 
0.26x before 0.28?

Randy.

[Module::Build] Re: Opting out of rt.cpan.org

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

Adam Kennedy wrote:
>> It's part of the 1.2 spec:
>>
>>  <http://module-build.sourceforge.net/META-spec-v1.2.html#resources>
> 
> On the subject of spec changes, I was wondering what people thought of 
> changing the dynamic_config option to become static_config or 
> static_metadata.
> 
> It seems silly that the default is 1, and thus the only time you need to 
> provide information is when you say
> 
> dynamic_config(0);

I've CC'd this to the module-build mailing list as it's probably a 
better place to ask.

I have to admit that I'm not totally sure what this option is for. There 
are a number of problems it could be intended to solve, but I'm not sure 
which one(s).

1) For automated builders/testers, it could indicate that a module 
requires user intervention. Eg. it queries the user for input during 
install.

2) The dependencies listed in META.yml are not static. Maybe a Win32::* 
module is required only when run under Windows, but is not listed in 
META.yml because there is currently no way to express conditional 
dependencies.

3) The description in the spec would seem to imply that a static config 
indicates that module can be installed without the builder (i.e. 
Module::Build)), that the modules could simply be copied into the proper 
folders by any tool. This would mean any module with with XS or compiled 
code as well as anything under (1) and (2) above are dynamic?

Randy.

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

[Yitzchak Scott-T. <sth...@ef...>]

On Mon, Mar 06, 2006 at 03:08:31PM -0600, Ken Williams wrote:
> 
> On Mar 6, 2006, at 2:59 PM, Yitzchak Scott-Thoennes wrote:
> 
> >
> >Rafael applied my patch to add 0.27_08 to the core today.
> >
> 
> Our day of reckoning is here! =)
> 
> Presumably this means we'll get lots of bug reports as people do  
> their smoke testing.  We'll have to be judicious about which bugs we  
> fix before 0.28 and which ones we don't, or else we'll never get 0.28  
> out the door.  I think probably only show-stopping bugs should get  
> fixed, and others can be listed as "known bugs" or whatever so people  
> know not to rely on them as behaviors.
> 
> Yizchak, thanks for generating all your patches.  That's a big help  
> for getting the integration to happen.

I'm hoping most of the trouble will be problems in the test framework,
and that we can fix those even if not show-stopping for most platforms.

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

On Mar 6, 2006, at 2:59 PM, Yitzchak Scott-Thoennes wrote:

>
> Rafael applied my patch to add 0.27_08 to the core today.
>

Our day of reckoning is here! =)

Presumably this means we'll get lots of bug reports as people do  
their smoke testing.  We'll have to be judicious about which bugs we  
fix before 0.28 and which ones we don't, or else we'll never get 0.28  
out the door.  I think probably only show-stopping bugs should get  
fixed, and others can be listed as "known bugs" or whatever so people  
know not to rely on them as behaviors.

Yizchak, thanks for generating all your patches.  That's a big help  
for getting the integration to happen.

  -Ken

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

[Yitzchak Scott-T. <sth...@ef...>]

On Sat, Feb 25, 2006 at 02:53:49PM -0600, Ken Williams wrote:
> 
> On Feb 19, 2006, at 12:00 AM, Adam Kennedy wrote:
> 
> >
> >And if we can clear Module::Build on 400-500 installations of Perl,  
> >I'd feel much more comfortable about seeing it head towards the core.
> 
> Holy crap!  Is this really the litmus test for core inclusion these  
> days?  Do we apply that standard to all modules?  It certainly wasn't  
> done for ExtUtils::ParseXS or ExtUtils::CBuilder (both of which were  
> offshoots of the Module::Build project).  They were just deemed to be  
> helpful additions with reasonable interfaces, so they were added.   
> I'd hope that same standard would apply here.

Rafael applied my patch to add 0.27_08 to the core today.

[Module::Build] Version 0.58 of YAML is installed, but we need version < 0.49

[<and...@fr...>]

  [...]
  Module-Build-0.2612/t/XSTest/lib/XSTest.xs
  Module-Build-0.2612/t/XSTest/MANIFEST
  Module-Build-0.2612/t/XSTest/test.pl
  WARNING: This key is not certified with a trusted signature!
  Primary key fingerprint: ADCB DB05 B40E B2A2 A555  5462 82BB CC04 B7EF 9476

    CPAN.pm: Going to build K/KW/KWILLIAMS/Module-Build-0.2612.tar.gz

  # running Build.PL
  /home/src/perl/repoperls/installed-perls/perl/p4pqpmS/perl-5.8.0@27350/bin/perl -Ilib Build.PL
  Checking whether your kit is complete...
  Looks good
  Feature 'YAML_support' disabled because of the following prerequisite failures:
   * Version 0.58 of YAML is installed, but we need version < 0.49


If this is not a bug, maybe a comment should be added in the Build.PL,
why it is needed.


-- 
andreas

[Module::Build] [PATCH] Missing META.yml fields

[Chris D. <ch...@cl...>]

If you use the "dist_name" style of Build.PL instead of  
"module_name", then you need to include the "dist_abstract" field  
too, or you will see the following error when running "Build distmeta":

   ERROR: Missing required field 'abstract' for META.yml

This is very misleading because it's the "dist_abstract" field that's  
missing, not "abstract".  The following simple patch changes the  
error message.  I've confirmed that with the patch it now says:

   ERROR: Missing required field 'dist_abstract' for META.yml

but I haven't tested any fields other than "abstract".

Chris

diff -u -r1.552 Base.pm
--- lib/Module/Build/Base.pm    4 Mar 2006 03:59:28 -0000       1.552
+++ lib/Module/Build/Base.pm    5 Mar 2006 20:45:41 -0000
@@ -3077,7 +3077,7 @@
    foreach (qw(dist_name dist_version dist_author dist_abstract  
license)) {
      (my $name = $_) =~ s/^dist_//;
      $node->{$name} = $self->$_();
-    die "ERROR: Missing required field '$name' for META.yml\n"
+    die "ERROR: Missing required field '$_' for META.yml\n"
        unless defined($node->{$name}) && length($node->{$name});
    }

-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

[Module::Build] [PATCH] missed this part when adding Tie::CPHash

[Yitzchak Scott-T. <sth...@ef...>]

This doesn't seem to have made it to the list; resending.

--- Module-Build-0.27_08/t/lib/MBTest.pm.orig	2006-03-03 19:27:57.000000000 -0800
+++ Module-Build-0.27_08/t/lib/MBTest.pm	2006-03-05 11:28:21.187500000 -0800
@@ -5,16 +5,17 @@
 use File::Spec;
 
 BEGIN {
+  # Make sure none of our tests load the users ~/.modulebuildrc file
+  $ENV{MODULEBUILDRC} = 'NONE';
+
   # In case the test wants to use Test::More or our other bundled
   # modules, make sure they can be loaded.  They'll still do "use
   # Test::More" in the test script.
   my $t_lib = File::Spec->catdir('t', 'bundled');
-  push @INC, $t_lib; # Let user's installed version override
 
-  # Make sure none of our tests load the users ~/.modulebuildrc file
-  $ENV{MODULEBUILDRC} = 'NONE';
-
-  if ($ENV{PERL_CORE}) {
+  if (!$ENV{PERL_CORE}) {
+    push @INC, $t_lib; # Let user's installed version override
+  } else {
     # We change directories, so expand @INC to absolute paths
     # Also add .
     @INC = (map(File::Spec->rel2abs($_), @INC), ".");
@@ -22,6 +23,8 @@
     # we are in 't', go up a level so we don't create t/t/_tmp
     chdir '..' or die "Couldn't chdir to ..";
 
+    push @INC, File::Spec->catdir(qw/lib Module Build/, $t_lib);
+
     # make sure children get @INC pointing to uninstalled files
     require Cwd;
     $ENV{PERL5LIB} = File::Spec->catdir(Cwd::cwd(), 'lib');

[Module::Build] [PATCH] missed this part when adding Tie::CPHash

[Yitzchak Scott-T. <sth...@ef...>]

--- Module-Build-0.27_08/t/lib/MBTest.pm.orig	2006-03-03 19:27:57.000000000 -0800
+++ Module-Build-0.27_08/t/lib/MBTest.pm	2006-03-05 11:28:21.187500000 -0800
@@ -5,16 +5,17 @@
 use File::Spec;
 
 BEGIN {
+  # Make sure none of our tests load the users ~/.modulebuildrc file
+  $ENV{MODULEBUILDRC} = 'NONE';
+
   # In case the test wants to use Test::More or our other bundled
   # modules, make sure they can be loaded.  They'll still do "use
   # Test::More" in the test script.
   my $t_lib = File::Spec->catdir('t', 'bundled');
-  push @INC, $t_lib; # Let user's installed version override
 
-  # Make sure none of our tests load the users ~/.modulebuildrc file
-  $ENV{MODULEBUILDRC} = 'NONE';
-
-  if ($ENV{PERL_CORE}) {
+  if (!$ENV{PERL_CORE}) {
+    push @INC, $t_lib; # Let user's installed version override
+  } else {
     # We change directories, so expand @INC to absolute paths
     # Also add .
     @INC = (map(File::Spec->rel2abs($_), @INC), ".");
@@ -22,6 +23,8 @@
     # we are in 't', go up a level so we don't create t/t/_tmp
     chdir '..' or die "Couldn't chdir to ..";
 
+    push @INC, File::Spec->catdir(qw/lib Module Build/, $t_lib);
+
     # make sure children get @INC pointing to uninstalled files
     require Cwd;
     $ENV{PERL5LIB} = File::Spec->catdir(Cwd::cwd(), 'lib');

Re: [Module::Build] should Pod::Readme vs. Pod::Text for README creation be a feature?

[Yitzchak Scott-T. <sth...@ef...>]

On Sat, Mar 04, 2006 at 11:28:34PM -0500, Randy W. Sims wrote:
> Yitzchak Scott-Thoennes wrote:
> >On Sat, Mar 04, 2006 at 10:06:19PM -0500, Randy W. Sims wrote:
> >
> >>Yitzchak Scott-Thoennes wrote:
> >>
> >>>Just as META.yml can be forced to build with or without YAML by setting
> >>>the YAML_feature, shouldn't README creation depend on a feature?
> >>>
> >>>The other discrepancy is that Pod::Readme is recommended but YAML is
> >>>not; seems to me both or neither should be listed in recommends: in
> >>>META.yml.  Same with the other feature-enabling modules.  If not,
> >>>what are the criteria for what goes in recommends: and what doesn't?
> >>
> >>The requirement for creating README can't be properly expressed with 
> >>current limitations; It depends on (Pod::Readme || Pod::Text). The best 
> >>we can do is recommend one or both.
> >
> >
> >Pod::Text has been in the core since 5.002.  But even if it wasn't,
> >Pod::Readme makes a better README file; Pod::Text is just a fallback.
> >Hence the recommendation.
> >
> >I see a parallel with YAML; YAML makes a better META.yml than the
> >fallback, so it should be recommended.
> 
> Sorry, I guess I forgot about Pod::Text being in core. I can see the 
> parallel. Would the attached patch be ok?

I'd rather see YAML added to recommends than Pod::Readme removed.
Seems to me they both fit the mission statement of recommends.
(But I'm wishing more and more Module::Build had started out as
separate user and author distributions.)
 
> Can I also suggest a slight rewording of the auto_features descriptions? 
> ( s/^Can (.)/\u$1/ )

Fine with me.  I went to check how config_data displays these and was
a little surprised to see that it didn't.

Re: [Module::Build] should Pod::Readme vs. Pod::Text for README creation be a feature?

[Randy W. S. <Ra...@Th...>]

Yitzchak Scott-Thoennes wrote:
> On Sat, Mar 04, 2006 at 10:06:19PM -0500, Randy W. Sims wrote:
> 
>>Yitzchak Scott-Thoennes wrote:
>>
>>>Just as META.yml can be forced to build with or without YAML by setting
>>>the YAML_feature, shouldn't README creation depend on a feature?
>>>
>>>The other discrepancy is that Pod::Readme is recommended but YAML is
>>>not; seems to me both or neither should be listed in recommends: in
>>>META.yml.  Same with the other feature-enabling modules.  If not,
>>>what are the criteria for what goes in recommends: and what doesn't?
>>
>>The requirement for creating README can't be properly expressed with 
>>current limitations; It depends on (Pod::Readme || Pod::Text). The best 
>>we can do is recommend one or both.
> 
> 
> Pod::Text has been in the core since 5.002.  But even if it wasn't,
> Pod::Readme makes a better README file; Pod::Text is just a fallback.
> Hence the recommendation.
> 
> I see a parallel with YAML; YAML makes a better META.yml than the
> fallback, so it should be recommended.

Sorry, I guess I forgot about Pod::Text being in core. I can see the 
parallel. Would the attached patch be ok?

Can I also suggest a slight rewording of the auto_features descriptions? 
( s/^Can (.)/\u$1/ )

@@ -51,28 +51,28 @@
     auto_features => {
  		     YAML_support =>
  		     {
-		      description => "Can write fully-functional META.yml files",
+		      description => "Write fully-functional META.yml files",
  		      requires => { YAML => ' >= 0.35, != 0.49_01 ' },
  		     },
  		     README_support =>
  		     {
-		      description => "Can write improved README files",
+		      description => "Write improved README files",
  		      requires => { 'Pod::Readme' => '0.04', },
  		     },
  		     C_support =>
  		     {
-		      description => "Can compile/link C & XS code",
+		      description => "Compile/link C & XS code",
  		      requires   => { 'ExtUtils::CBuilder' => 0.15, },
  		      recommends => { 'ExtUtils::ParseXS'  => 1.02, },
  		     },
  		     manpage_support =>
  		     {
-		      description => "Can create Unix man pages",
+		      description => "Create Unix man pages",
  		      requires => { 'Pod::Man' => 0 },
  		     },
  		     HTML_support =>
  		     {
-		      description => "Can create HTML documentation",
+		      description => "Create HTML documentation",
  		      requires => { 'Pod::Html' => 0 },
  		     },
  		    },

Re: [Module::Build] should Pod::Readme vs. Pod::Text for README creation be a feature?

[Yitzchak Scott-T. <sth...@ef...>]

On Sat, Mar 04, 2006 at 10:06:19PM -0500, Randy W. Sims wrote:
> Yitzchak Scott-Thoennes wrote:
> >Just as META.yml can be forced to build with or without YAML by setting
> >the YAML_feature, shouldn't README creation depend on a feature?
> >
> >The other discrepancy is that Pod::Readme is recommended but YAML is
> >not; seems to me both or neither should be listed in recommends: in
> >META.yml.  Same with the other feature-enabling modules.  If not,
> >what are the criteria for what goes in recommends: and what doesn't?
> 
> The requirement for creating README can't be properly expressed with 
> current limitations; It depends on (Pod::Readme || Pod::Text). The best 
> we can do is recommend one or both.

Pod::Text has been in the core since 5.002.  But even if it wasn't,
Pod::Readme makes a better README file; Pod::Text is just a fallback.
Hence the recommendation.

I see a parallel with YAML; YAML makes a better META.yml than the
fallback, so it should be recommended.

Re: [Module::Build] should Pod::Readme vs. Pod::Text for README creation be a feature?

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

Yitzchak Scott-Thoennes wrote:
> Just as META.yml can be forced to build with or without YAML by setting
> the YAML_feature, shouldn't README creation depend on a feature?
> 
> The other discrepancy is that Pod::Readme is recommended but YAML is
> not; seems to me both or neither should be listed in recommends: in
> META.yml.  Same with the other feature-enabling modules.  If not,
> what are the criteria for what goes in recommends: and what doesn't?

The requirement for creating README can't be properly expressed with 
current limitations; It depends on (Pod::Readme || Pod::Text). The best 
we can do is recommend one or both.

Features wouldn't be appropriate in this case, because we still have to 
explicitly test for the presence of one or the other of the modules. We 
can't query ::ConfigData to determine what method to use.

Randy.


Hmm, only ~40 unread mails or mails marked for follow-up left in my 
Module::Build folder...

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] ./Build on Win98

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

Ken Williams wrote:
> 
> On Mar 3, 2006, at 7:04 PM, Randy W. Sims wrote:
> 
>>
>> After further cleanup and testing, I've checked in the changes with  
>> doc tweaks.
>>
> 
> Great.  I've released the current snapshot (before adding the  
> testpodcoverage action) as a new beta.
> 
> Very Little To Do Before 0.28 Now.

Cool.

Much thanks to Dr Bean, Ron, Yves, and others who helped with testing, 
isolating the problem and providing feedback.

Randy.

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 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

[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