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

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

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