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