Thread: [Module::Build] M::B and no_index

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Does M::B (0.2612) support the no_index property and if so, how can I
use it?

-- Johan

Johan Vromans wrote:
> Does M::B (0.2612) support the no_index property and if so, how can I
> use it?

On 0.27+, I've used this as an argument in Build.PL:

     meta_add            => {
         no_index            => { dir => [ qw/examples/ ] }
     },

I don't think there is an equivalent on 0.2612.  However, if you 
generate your META.yml with 0.27, it still "works" for users with 0.2612 
as it's not used at install time.  I.e. I use 0.27 but with 0.26 
compatible build, test and install features.  I use 0.27 specific 
features only for distribution creation.

Are you unable to upgrade M::B to the 0.27 beta?

Regards,
David Golden

David Golden <da...@hy...> writes:

> [...] it still "works" for users with 0.2612 as it's not used at
> install time.

The first thing that M::B does when using "Build dist" is removing an
existing META.yaml...

> Are you unable to upgrade M::B to the 0.27 beta?

Maybe, if I would be able to find it. It's not on CPAN.

SourceForge only has 0.2611 and a 0.27_01 which seems to be older than
0.2611. CPAN has 0.2612.
The SourceForge home page for M::B only lists META-spec files...
Confusing, at least.

-- Johan

Johan Vromans wrote:
> David Golden <da...@hy...> writes:
>> Are you unable to upgrade M::B to the 0.27 beta?
> 
> Maybe, if I would be able to find it. It's not on CPAN.

That's funny, I see 0.27_01 through 0.27_09 on this page:

	http://search.cpan.org/~kwilliams/Module-Build-0.2612/

under "Latest Dev. Release" and "Other Releases."  How are you trying to 
install (CPAN or CPANPLUS)?

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

John Peacock <jpe...@ro...> writes:

> Johan Vromans wrote:
>> David Golden <da...@hy...> writes:
>>> Are you unable to upgrade M::B to the 0.27 beta?
>> Maybe, if I would be able to find it. It's not on CPAN.
>
> That's funny, I see 0.27_01 through 0.27_09 on this page:
>
> 	http://search.cpan.org/~kwilliams/Module-Build-0.2612/
>
> under "Latest Dev. Release" and "Other Releases."  How are you trying
> to install (CPAN or CPANPLUS)?

I use a CPAN mirror. Interesting is that 0.27_01 through 0.27_09 are
in authors/id/KWILLIAMS, but not in modules/by-module/ (apparently
since it's beta). Okay, now I've found it I'll give it a try.

Thanks.

-- Johan

Johan Vromans wrote:
> I use a CPAN mirror. Interesting is that 0.27_01 through 0.27_09 are
> in authors/id/KWILLIAMS, but not in modules/by-module/ (apparently
> since it's beta).

Yeah, that's how CPAN works.  The only stuff in modules/by-module/ (and 
hence the indexes) is the official releases (non-alpha).

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Johan Vromans <jvr...@sq...> writes:

> Okay, now I've found it I'll give it a try.

This version seems to cure a lot of problems. Nice.

However, for the time being, I think it's better to distribute this
version of M::B together with the application. While it is trivial to
add a "use lib '.';" to the Build.PL, how can I achieve this with the
generated Build script?

-- Johan

Johan Vromans wrote:
> Johan Vromans <jvr...@sq...> writes:
> 
>> Okay, now I've found it I'll give it a try.
> 
> This version seems to cure a lot of problems. Nice.
> 
> However, for the time being, I think it's better to distribute this
> version of M::B together with the application. While it is trivial to
> add a "use lib '.';" to the Build.PL, how can I achieve this with the
> generated Build script?

In the Module::Build directory, run

   perl Build.PL
   ./Build

Then copy 'blib/lib' to your distro:

   cp -r blib/lib/* ~/Foo/inc/

Then write your Build.PL something like:

use strict;
use warnings;

use lib 'inc';
use Module::Build;

use Cwd;
my $cwd = cwd();

my $build_class = Module::Build->subclass(code => <<"---");
use File::Spec;
my \$inc = File::Spec->catdir("$cwd", 'inc');
unshift(\@INC, \$inc);
use Module::Build;

sub ACTION_version {
   print qq(Using Module::Build version \$Module::Build::VERSION\n);
}
---

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

$builder->create_build_script();

__END__

Regards,
Randy.

Randy W. Sims wrote:
> Johan Vromans wrote:
>> Johan Vromans <jvr...@sq...> writes:
>>
>>> Okay, now I've found it I'll give it a try.
>>
>> This version seems to cure a lot of problems. Nice.
>>
>> However, for the time being, I think it's better to distribute this
>> version of M::B together with the application. While it is trivial to
>> add a "use lib '.';" to the Build.PL, how can I achieve this with the
>> generated Build script?
> 
> In the Module::Build directory, run
> 
>   perl Build.PL
>   ./Build
> 
> Then copy 'blib/lib' to your distro:
> 
>   cp -r blib/lib/* ~/Foo/inc/
> 
> Then write your Build.PL something like:

Actually, the build script should work fine without those changes. I 
just remembered that we store the @INC and hard code it into the 'Build' 
script. So, after coping as above, this 'Build.PL' should work fine:

use strict;
use warnings;

use lib 'inc';
use Module::Build;

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

$builder->create_build_script();

__END__

"Randy W. Sims" <ml...@th...> writes:

> the build script should work fine without those changes. I just
> remembered that we store the @INC and hard code it into the 'Build'
> script.

> use lib 'inc';
> use Module::Build;
>
> ...
>
> $builder->create_build_script();

1. Almost. For example, I use "use lib '.'" to get '.' as the first
   location to try. In the default perl @INC, '.' is the last entry.
   But since '.' occurs in the default @INC, it will not be written to
   the Build script, and the effect of "use lib '.'" is lost.

   Now, I cannot imagine people deliberately mixing up @INC, but
   putting '.' in front seems not uncommon to me. Why not change the
   "push @INC ..." code to "@INC = ( ... )" and supply the exact
   actual inc path?

2. This is also the easiest solution for me: move the addtional
   modules to inc and all is fine. No other changes necessary.

Thanks for the good work!

-- Johan

Johan Vromans wrote:
> "Randy W. Sims" <ml...@th...> writes:
> 
> 
>>the build script should work fine without those changes. I just
>>remembered that we store the @INC and hard code it into the 'Build'
>>script.
> 
> 
>>use lib 'inc';
>>use Module::Build;
>>
>>...
>>
>>$builder->create_build_script();
> 
> 
> 1. Almost. For example, I use "use lib '.'" to get '.' as the first
>    location to try. In the default perl @INC, '.' is the last entry.
>    But since '.' occurs in the default @INC, it will not be written to
>    the Build script, and the effect of "use lib '.'" is lost.
> 
>    Now, I cannot imagine people deliberately mixing up @INC, but
>    putting '.' in front seems not uncommon to me. Why not change the
>    "push @INC ..." code to "@INC = ( ... )" and supply the exact
>    actual inc path?

I don't see any other way around this if we want to preserve order of 
@INC correctly. Either we restore the exact contents of @INC when 
running Build or if we think the @INC is going to have more additions 
beteen invokations we can do something like in the attached patch.

Any thoughts on this Ken?

Randy.

Johan Vromans wrote:
> "Randy W. Sims" <ml...@th...> writes:
> 
> 
>>the build script should work fine without those changes. I just
>>remembered that we store the @INC and hard code it into the 'Build'
>>script.
> 
> 
>>use lib 'inc';
>>use Module::Build;
>>
>>...
>>
>>$builder->create_build_script();
> 
> 
> 1. Almost. For example, I use "use lib '.'" to get '.' as the first
>    location to try. In the default perl @INC, '.' is the last entry.
>    But since '.' occurs in the default @INC, it will not be written to
>    the Build script, and the effect of "use lib '.'" is lost.
> 
>    Now, I cannot imagine people deliberately mixing up @INC, but
>    putting '.' in front seems not uncommon to me. Why not change the
>    "push @INC ..." code to "@INC = ( ... )" and supply the exact
>    actual inc path?

I don't see any other way around this if we want to preserve order of 
@INC correctly. Either we restore the exact contents of @INC when 
running Build or if we think the @INC is going to have more additions 
beteen invokations we can do something like in the attached patch.

Any thoughts on this Ken?

Randy.

On Apr 9, 2006, at 12:26 AM, Randy W. Sims wrote:

>
> I don't see any other way around this if we want to preserve order  
> of @INC correctly. Either we restore the exact contents of @INC  
> when running Build or if we think the @INC is going to have more  
> additions beteen invokations we can do something like in the  
> attached patch.
>
> Any thoughts on this Ken?

Well, we used to indeed set @INC directly, but we stopped doing it in  
December 2004.  Schwern wrote the patch.  The following entries in  
the 'Changes' file are probably relevant:

=================================
0.2608  Wed Jan 26 19:46:09 CST 2005

[...]
- Work around some bad mojo between Fedora Core [with its very long
    @INC] and old versions of Test::Harness [with its propensity to
    compound the number of @INC entries] that produced an "argument
    list too long" error during testing.  [assisted by Ville Skytta,
    David Golden, & Randy Sims]
[...]

0.2607 (Bug fix release in 0.26 series)  Sat Dec 18 14:14:09 CST 2004

- Instead of freezing @INC in the 'Build' script to the value it had
    when Build.PL was run, we now just add those additional values that
    aren't part of the default compiled-in @INC. [Michael Schwern]

- The run_perl_script() method will now propagate any extra entries
    in @INC (such as those added by "use lib" or the -I command-line
    switch) to the subprocess.  This helps situations in which you want
    to tell the subprocess where to find a certain module, for
    instance.  [Michael Schwern]

=================================

Those considerations aside, I'm still of a split mind about this.  On  
the one hand, if you do @INC=(...) you've got a better chance of  
getting things right, but it can feel too rigid for the user who  
wants to change INC on the fly.  On the other hand, if you do push 
(@INC, ...) then you probably mess up the order of INC even relative  
to its original value, but someone can sneak in some extra paths if  
they want to.

Probably @INC=(...) is marginally better, though?

  -Ken

Ken Williams wrote:
> 
> On Apr 9, 2006, at 12:26 AM, Randy W. Sims wrote:
> 
>>
>> I don't see any other way around this if we want to preserve order  of 
>> @INC correctly. Either we restore the exact contents of @INC  when 
>> running Build or if we think the @INC is going to have more  additions 
>> beteen invokations we can do something like in the  attached patch.
>>
>> Any thoughts on this Ken?
> 
> 
> Well, we used to indeed set @INC directly, but we stopped doing it in  
> December 2004.  Schwern wrote the patch.  The following entries in  the 
> 'Changes' file are probably relevant:
> 
> =================================
> 0.2608  Wed Jan 26 19:46:09 CST 2005
> 
> [...]
> - Work around some bad mojo between Fedora Core [with its very long
>    @INC] and old versions of Test::Harness [with its propensity to
>    compound the number of @INC entries] that produced an "argument
>    list too long" error during testing.  [assisted by Ville Skytta,
>    David Golden, & Randy Sims]
> [...]
> 
> 0.2607 (Bug fix release in 0.26 series)  Sat Dec 18 14:14:09 CST 2004
> 
> - Instead of freezing @INC in the 'Build' script to the value it had
>    when Build.PL was run, we now just add those additional values that
>    aren't part of the default compiled-in @INC. [Michael Schwern]
> 
> - The run_perl_script() method will now propagate any extra entries
>    in @INC (such as those added by "use lib" or the -I command-line
>    switch) to the subprocess.  This helps situations in which you want
>    to tell the subprocess where to find a certain module, for
>    instance.  [Michael Schwern]
> 
> =================================
> 
> 
> Those considerations aside, I'm still of a split mind about this.  On  
> the one hand, if you do @INC=(...) you've got a better chance of  
> getting things right, but it can feel too rigid for the user who  wants 
> to change INC on the fly.  On the other hand, if you do push (@INC, ...) 
> then you probably mess up the order of INC even relative  to its 
> original value, but someone can sneak in some extra paths if  they want to.
> 
> Probably @INC=(...) is marginally better, though?

I'm not sure what to do about this one.

1.) We can strictly record the @INC at the time 'Build.PL' is run, we 
can check it against @INC when './Build' is run, and if it is different, 
we can warn the user. CON: User cannot take advantage of changes to @INC 
/after/ running 'Build.PL' without re-running it.

2.) We can add any changes to @INC to the beginning or the end of the 
original @INC. This will allow the user to add entries either with -I 
option or by setting env PERL5LIB, etc. CON: Do the uniq entries go at 
the beginning or end; there is no clear choice.

I'm leaning heavily on (1) at the moment because it is well defined and 
we alread warn about other changes in the environment. Also, I don't see 
much advantage to have a differing @INC between 'Build.PL' and 
'./Build', so nothing is lost.

Randy.

On Apr 24, 2006, at 12:44 AM, Randy W. Sims wrote:
> I'm not sure what to do about this one.
>
> 1.) We can strictly record the @INC at the time 'Build.PL' is run,  
> we can check it against @INC when './Build' is run, and if it is  
> different, we can warn the user. CON: User cannot take advantage of  
> changes to @INC /after/ running 'Build.PL' without re-running it.
>
> 2.) We can add any changes to @INC to the beginning or the end of  
> the original @INC. This will allow the user to add entries either  
> with -I option or by setting env PERL5LIB, etc. CON: Do the uniq  
> entries go at the beginning or end; there is no clear choice.
>
> I'm leaning heavily on (1) at the moment because it is well defined  
> and we alread warn about other changes in the environment. Also, I  
> don't see much advantage to have a differing @INC between  
> 'Build.PL' and './Build', so nothing is lost.

The original use case for all this @INC munging is that when the  
author puts a "use lib" or a "push @INC" or whatever in their  
Build.PL script, the effect on @INC ought to be seen in the Build  
script too.

That means that a strict interpretation of (1) isn't workable.  It  
would also break backwards compatibility with existing Build.PL scripts.

If we can't figure out some smart version of (2) that we like, we  
should just defer this to a later version and not try to fix it for  
0.28.

  -Ken

Randy W. Sims wrote:
> In the Module::Build directory, run
> 
>   perl Build.PL
>   ./Build
> 
> Then copy 'blib/lib' to your distro:
> 
>   cp -r blib/lib/* ~/Foo/inc/

And don't forget to add inc/ to your META.yml 'no_index' list.

David

On Mar 24, 2006, at 08:54, Johan Vromans wrote:

> SourceForge only has 0.2611 and a 0.27_01 which seems to be older than
> 0.2611. CPAN has 0.2612.
> The SourceForge home page for M::B only lists META-spec files...
> Confusing, at least.

There's always CVS. That's where I get it.

   http://sourceforge.net/cvs/?group_id=45731

Best,

David

Thread: [Module::Build] M::B and no_index

module-build-general