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

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

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.