# from brian d foy # on Monday 28 September 2009 11:24: >What is resume() for, then?
That's an excellent question. The docs say: "You'll probably never call this method directly ...", so you've won the obscurity prize. ;-) Seriously though, you've left the realm of test coverage and mainstream usage. >Can't @INC also be stored in _build/config? That seems like it could make a mess of things. Storing it in Build addresses the process disconnect between Build.PL and later actions. That has some DWIM to it which is already somewhat fragile. Maybe that could be cleaned-up and normalized but when we read @INC and try to decide what changed or what to put back and whether we've left the process and returned (or suffered some local @INC = ...), or if it was PERL5LIB, or 'use lib' in Build.PL, or whatever ... it gets complicated. Obviously having some parameter or formalism to modify @INC would simplify that. Of course, maybe it has already gotten as complicated as it gets and we just have to push through. The current unshift(@INC, ...) in ./Build is already naive and redundant on PERL5LIB but deals with the issue of somebody running Build.PL with a temporary PERL5LIB necessary to find M::B. >> Is there a reason that you don't want to shell out to "./Build >> test"? > >I'm not running the test target. I'm doing something much more >complicated where I have to interact with the module::build subclass >object and finally run an action. So you're running Build.PL in a different process, it does a "use lib 'inc'", and then you want resume() to deal with that? If so, it's probably doable, but hasn't been done. How did you get past this bit in resume()? eval "require $build_class; 1" or die "Failed to re-load '$build_class': $@"; --Eric -- As an old bass player friend of mine used to say: throw money, don't clap. --Tony Parisi --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------